[REBOL] Re: Rebol Framework suggestion
From: chrismorency:videotron:ca at: 16-Sep-2001 1:32
> What if we start by creating some libraries. We should be able to get at
> least some small consensus on a reasonable taxonomy from the people here.
> The RT script library is categorized and provides lots of great
> examples in
> specific contexts but, for people just learning REBOL (like me), it can be
> quite time consuming to sift through the code in the examples to find the
> bits you need and extract them.
Exactly, currently all scripts are interresting, doing specific or general
things, however we still have to look at other's script to dig the stuff and
put it in our code (especially for view)... why can't we could simply linked
an online library. For example, the scrolling function for text-area and
scroll-bars, why this script is not within an add-on view library I could
link... and it would work for my script and others ? without having me going
in the RIM to get it out ?
> I may be unusual but, as much as I like just grabbing something that works
> and using it, I really like to undertand the tool(s) I'm using. That means
> taking apart the RT examples and figuring out what each little
> piece does so
> I can extract and generalize the bits I need. I'm building up a collection
> of my own functions and I'll need to organize them somehow, so
> why not kill
> two birds with one stone.<g>
I'm currently doing the same.
> What if we use contexts for namespacing to manage libs? For example, we
> could use contributors initials as the top level.
<initial example snipped> I have take the habit of naming my script like
cm-script-name.r so I know this is something I work on myself. When I take
script from the library and change it for my own needs, I do the same but I
still leave the author info... This is to remind me that this has been
modified, but it's not mine ;)
> Alternately, you use the category names as the top level and then just
> include comments about the contrbutors, if so desired. A key will be
> simplcity in the naming. That is to say, making sure that using
> the standard
> library functions doesn't add so much prefixing that readability suffers.
> Using a single special character as a prefix, or suffix, might be less
> intrusive than a "-lib" suffix (as in the example below).
> *math math* math-lib
> *str str* str-lib
> *obj obj* obj-lib
> *gfx gfx* gfx-lib
Good idea ! Maybe RT would gladly make a Library folder, where we could put
generic stuff that can be reused in other scripts directly... Those library
shouldn't do anything on their own. They should be dialects, functions,
objects, etc. Also, the script headers should list all of the global words
which will be used for the script, so an author would knwo if there is any
conflict with his own script... maybe we would need some kind of naming
convention like you mention above...
> I don't know what the tradeoffs are between loading a large library of
> functions into the global space versus putting them in contexts.
> I.e. are we
> going to pollute the global space horribly or do we suffer a
> memory or performance penalty by using contexts?
I'm sure we should go with contexts and dialects, although I havent played
with that yet... or Objects, which is the way I've taken so far because it
makes sense for me (I can understand others would not be interested in OOP)
> We could also (well, we meaning someone who knows what they're doing <g>)
> build a tool that would extract only the required definitions and combine
> them into a deployment file. That way you could develop with the whole
> library but then take a "snapshot" of the functions you use and
> put them all
> in a single file for distribution. Pros? Cons?
Good idea, I also think that libraries should be analyze first by a group of
people (mailing list?) in order to check their quality, evaluate eventual
modification to make them better and more readable to user. We can't afford
to put snippets of codes with strange functions name and arguments that
nobody will understand.
> I'm open to critiques and comments on all sides. I don't think we want to
> build a big, complex, unREBOLish beast but just a more granular
> library that people can use and learn from.