Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: Enabling the REBOL community

From: agem:crosswinds at: 9-May-2001 18:36

>>>>>>>>>>>>>>>>>> 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 & 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 :)