[REBOL] Re: [Fwd: Re: RSL: Rebol Standard Library]
From: gjones05:mail:orion at: 24-May-2001 10:38
Hi, Joel,
I'm not including any of your message for the sake of download brevity.
Those who need the original are referred to:
http://www.escribe.com/internet/rebol/m9432.html
I am in agreement with the general scheme that you have laid out.
Pardon me in advance if I have misunderstood anything you have said, but
here are some additional thoughts (in regard to your posting the other
day and today):
I like the idea of careful namespace protection and importing only the
aspects of the implementation needed. These ideas are smart and
efficient.
The way in which versioning is managed is also important. Tcl (and I'm
sure numerous other languages) allows for a flexible use of packages,
and in fact uses the keyword package. Tcl has several refinements of
this command. One refinement is "package require" type statement that
can specify a specific version of module. Tcl looks in a configured
path for the package and halts if that package in that version is not
available. Tcl folks have done a fair amount of thinking about
packages, and I suspect that we could borrow the best from the them and
leave the rest.
Link to on-line man pages that cover the package command:
http://dev.scriptics.com/man/tcl8.3.2/TclCmd/package.htm
I can see packages (or modules or what-ever form of generic name) being
either literally included by the application author (like an automatic
form of a cut and paste) after being loaded into the public path or that
the application makes reference to a package that is to be included in
the public path. If not there, then the user's instance of the
application requests the package piece from the Internet store.
Tcl does not include any simple, (semi-)automated method for retrieving
a package if it is not available locally (it could be done; it's just
not done simply). Here is where REBOL clearly excels. However, with
the flexibility and power for an application to look on the net for a
required package, comes the responsibility that the "right" package is
delivered (or sub-component, as you have proposed). I agree that
package naming should be consistent from version to version, but as in
all things, deprecation and/or extension will occur that will hinder
compatibility. The only (non-exclusive) options are to give the module
a new name or to make version use an explicitly configurable option.
Say, for example, a package had versions 1.0, 1.1, and 1.2 that where
basically backwards compatible, but that version 2.0 required a change
in implementation that could not be hidden. Older applications might
still need live access to the older versions of the package; whereas,
newer applications would need access to newer versions. As long as the
various stable versions were always available, an application could
specify that "only" a specific version could be used. Tcl (if I recall
correctly) does not allow this sort of flexibility; it only allows for a
minimum package version allowed (if I'm wrong, sorry Tcl'ers). I think
a robust package managment system could allow for a robust variation in
how applications are woven together. Yes, increased complexity, but I
believe that it is manageable if done from the outset. Merely/only
*replacing* older packages with newer packages opens up the kind of
problems that Microsoft developed with their method of redistributable
libraries. I am not terribly familiar with CVS, but I guess the ideal
method taps into a CVS tree to either get the right version and/or the
most recent version, depending on the application developers needs and
intentions.
Whew, did that make any sense, I ask myself while chewing on lead paint
chips?!?! Hopefully, the essence shines through my sleep-deprived
prose.
The other point that has come readily to mind is that these
modules/packages should have their own regression testing section
available. This was a requirement at one time for the "Tcl Standard
Library," which allowed developers of more complex applications to have
these tests available for whole-project regression testing. I thought
this was a really slick idea, as a way to be sure that processes are not
interfering with one another and invalidating the coding logic.
Just some incoherent thoughts. May I be excused? ;-)
Thanks for the thoughtful contributions to date from all parties. Nice
work, **as usual**, Joel. ;-)
--Scott Jones
