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

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