[REBOL] Re: Enabling the REBOL community
From: agem:crosswinds at: 9-May-2001 18:36
Below..
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 09.05.01, 14:15:22, schrieb Joel Neely <[joel--neely--fedex--com]> zum
Thema [REBOL] Re: Enabling the REBOL community:
> Hi, Volker,
> Fair questions, but experience with such mechanisms in other
> communities can suggest some answers. A comprehensive
> unit management scheme (I think I'll stick with calling it
> UHURU until we can take a community vote/poll) addresses
> a number of software engineering issues and community
> development issues, both of which I think would benefit
> REBOL. (And I know that we all agree on THAT goal!)
> Volker Nitsch wrote:
> >
> > Doesn't we have read-thru?
> > Why another mechanism?
> >
> READ-THRU might very well be *part* of the mechanism, but it
> isn't a complete answer to the fundamental issues being raised.
> * You still have to have a source URL. What if you don't know
> which of several dozen uncoordinated volunteer sites has the
> unit you need? UHURU should support multiple mirror sites
> with the identical "community standard" content. When I go
> to get a unit, I should be able to tell UHURU to get me a
> unit by its community standard designation, and let UHURU
> deal with switching mirrors due to downed servers, etc.
> * The whole business of "community standard designation" is
> a BIG DEAL when the volume of available content begins to
> scale up. The REBOL/View desktop currently shows 28
> "Reb sites". In addition, I think there are about another
> dozen web sites not directly exposed as "Reb sites". If I
> know that somebody implemented a nice block-to-xml output
> function, I now have to keep up with (or search through)
> about three dozen places it might be. What will I do when
> there are a few hundred active contributors of REBOL code?
> (Or, more realistically, will there EVER be a few hundred
> as long as we don't have an effective publishing system?)
> OTOH, if somebody writes that nice block-to-xml output
> function and submits it to UHURU under the path
> /xml
> or
> /xml/unparse
> (or whatever the community establishes), then I can find it.
> This subject-based (instead of contributor-based) structure
> also lets me effectively (i.e., by concept) search the UHURU
> library tree for new submissions that might be useful to me.
> >
> > Then, i find cut&paste often more usefull then wrapping with objects,
> > since i can hack it to fit my needs.
> >
> You're certainly entitled to practice reuse by cut-and-paste if
> it works for you (and nothing in my proposals would prevent that
> practice), but it is totally unsatisfactory for my needs. One
> simple example suffices for my concern.
> I've written a unit that implements some generic traversal and
> processing functions over the block structures produced by the
> built-in XML parser. I've used that unit in many specific
> applications. A while back, I thought of a way to enhance the
> performance of one of its methods.
> Since the unit was maintained in a separate source file and
> "include"-ed where needed, I was able to implement the improvement
> in that one file. Every other piece of code that used it got
> the benefit the next time it was executed. If I had been using
> cut-and-paste, the amount of labor required to make (universally)
> that improvement would have been arbitrarily larger. I don't
> have time to go around and manually re-tweak N+1 copies of the
> same source, pasted into N+1 different places.
> >
> > Means, if i have a sceleton for a subdir-search i can
> > change it to report the files i want, with/without dirs and so on.
> > That flexibility pre-coded would need a lot of inbuild options.
> >
> I'm not sure I understand. If we separate out the list of
> paths from the core UHURU code, then let you configure it on
> your own system to search a specified list of paths in a specified
> order, that gives you the flexibility without having to explicitly
> set options all over the place. Or did I misunderstand your point?
Well, iam a rebol-recycler.
My current source are the script-librarys from rebol.com & rebol.org.
I have a little tool (%sucher6.r on my rebsite now),
which scans its directory and all subs for some words.
Download the script-libs, put it in the root and start..
Usually i get good suggestions after some trials
(well, i know approxemately whats in the libs).
I can't remember a script which i havent changed a bit to fit my
needs.
So »download and use« would not work in my case.
On the other hand, iam a dirty programmer in rebol,
more experimenting than planning.
I often use values which are occasionally in some var in
this specific version and so on. its simply faster written.
So featuring a library-script has sometimes broken other scripts
using it.
After that iam use copys of the original script which i can rely on
and
modify freely.
That means to, i can put a lot of project-specific debug-info
in lib-scripts.
More the prototype-style than the class-hirarchie :)
I accept your system, but for me that is java:
strong controlled, well documented apis with a lot of
configuration-options to fit all needs.
It works -hm- if you are very experienced with designing
and spend some time in it.
Its not so usable with reusing ad-hoc-scripts.
They need frozen code instead of frozen aps IMHO.
And patching instead of inheritance.
Well, after all they are shorter than javadoc-apis :)
> -jn-
Volker
ps. thinking about it, i pointed %sucher6.r to %public.
Now i can look up all scripts i looked at. Interesting..
Nice i can change the dirs in a script-copy :)
