[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}
