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

[REBOL] Open source project Re:(2)

From: joel:neely:fedex at: 6-Oct-2000 11:43

Hi, Petr, Actually, I believe we are in violent agreement about almost everything you said! I'm exerting MASSIVE amounts of self-control not to copy your entire note and insert "YES!" after every sentence. With that said... [Petr--Krenzelok--trz--cz] wrote:
[...points of STRONG agreement snipped...]
> The project should introduce top matrice for other projects as rebmail > for e.g. But really - I would still prefer seeing modules introduced > in REBOL rather than all that file & co requesters, as without it, we > can't know how it will affect our general aproach we are about to > introduce. >
You're right that details of future REBOL features -- modules, components, or whatever -- could affect (for good OR for ill) any code-sharing tools we may define and build. We need to keep that firmly in mind. But... 1) I assume that these postulated future features will be language extensions to make code re-use simpler AT THE CODING LEVEL. My experience with OO and code re-use is that, even when the language and/or development environment have mechanisms to allow/support/promote code re-use, that FINDING THE RIGHT PIECE OF CODE TO RE-USE is still a significant problem, and is made worse as the inventory of re-usable code grows larger. That was more the central issue of my proposal. 2) As much as I'd like to see a module! type, some enhancements to the current object! type (or a new datatype that provides added services), and other things we could add (such as a fix for the extended context GC bug...), we don't know the timeline for those things. I'm making the leap of faith that a distributed code repository that would support the current state of REBOL/Core could be extended/enhanced/modified to take advantage of any new capabilities RT subsequently provides. And (let me hasten to be fair!), RT has a lot on their to-do list! If it came to a choice between just the three above, I'd be happy to see all their attention go to bug-killing before designing/building new language features. BY THE WAY -- THANKS, CARL, FOR THE NEW USERS' GUIDE! IT'S A MAJOR STEP FORWARD! 3) If we could persuade RT that we have a critical mass of developers who will help solve the "social engineering" problem of (1), they might be willing to do one or more of the following (and I'd be willing personally to sign a non-disclosure agreement if that's what it took): 3.1) Give us hints about the timeline for the futures of (2), 3.2) Give us hints about what's coming so we don't paint ourselves into too much of a corner, 3.3) Tell us what's coming so we can plan for it explicitly, 3.4) Work with us to let each effort help influence the features and schedule of the other.
> Still - is here anyone who remembers Dick Whitings set of automatic > installation, localisation, extended help, examples, various category > function libraries etc? It's still the most complete set of script and > concepts introduced to REBOL. We should build something similar .... >
I believe I saw a URL for it many months ago (and looked at it briefly), but would be VERY grateful if someone could re-post it. IIRC it was oriented toward REBOL/Core/1.x and contained - some features now in /Core - some routines that would need to be rewritten due to 1.x-vs-2.x language changes - a generous collection of still-very-useful tools So, bringing up to date would be A Good Thing. Of course that begs the questions, "Where would we put it, how would people find it, and which part of it does what I need right now (without my having to read all of the source)?" Those are the kinds of issues my proposal was intended to address. -jn- -- ; Joel Neely [joel--neely--fedex--com] 901-263-4460 38017/HKA/9677 REBOL [] print to-string debase decompress #{ 789C0BCE0BAB4A7176CA48CAB53448740FABF474F3720BCC B6F4F574CFC888342AC949CE74B50500E1710C0C24000000}