"In some way" has been quoted negatively, twice.
Note that it is preceded by "official" which means that there is yet, no official way to do it, but if there was, THEN there would be no complication, there would be "a way" to do it, supported, documented and used by more than one person. Much like rugby, make-doc(pro) and many other tools have become rebol standards, through intersting featureset and adequate support. there is a lot of talk of the "dark side" of run-time linking and the fear it inspires... here is one little proactive view of the good side of run-time linking: -------- By leaving a library module external, the user can upgrade parts of his code without you needing to tamper with newer/better/faster versions of other peoples tools, you use. Remember that the point in creating an officially sharable module, is that it LOCKS an api. much like amiga's APIs are locked yet frequently improved. If something cannot be successfully patched, extend the api. This keeps older softwares using the library still 100% functional, while leaving new options for more up to date users. When the changes are too drastic, maybe its time for a big version number increase or a new library altogether. The library still is a rebol script, so (if the library's license permits it) you can still just copy the code in your application if you prefer. Also, something which is to be noted, is that some libraries could be meant for inter process tasks, its much more stable if both apps use the same version of a library module, which will not be the case if both include the code instead of linking to it at run-time. Again, this all depends on the quality of the api which is included in the library a script uses. If the author of a library keeps adding buggy changes, then yes, you are better off copying his code, since you aren't confident that his next version will be compatible... which would make your dependent app unstable. But by definition, creating an "officialy released" library module means that you must put though and design in the API of your tool. I am not trying to prove you wrong, I'm just illustrating, for anyone listening to the discussion, some of the real advantages of keeping code external, when the code itself is well planned and implemented. peace! ;-) -MAx --- "You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun." > -----Original Message----- > From: "Robert M. Münch" [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 13, 2003 9:43 AM > To: [EMAIL PROTECTED] > Subject: [REBOL] Re: DLL Hell = Rebol library script version > > > > On Tue, 11 Nov 2003 10:49:21 -0500, Maxim Olivier-Adlhoch > <[EMAIL PROTECTED]> wrote: > > > > what do you do when the included scripts totalize more than > 500k of code? > > do you create a 501KB file for each script? > > Yes. Why not? > > > why is run-time linking so bad if the engine is > standardized and the > > resources are centralized and "official" in some way? > > "...in some way" That's the problem. There is more than one > way to do it. > One EXE file is simple to move, copy, distribute etc. Users > just download > it, start it, use it. That's it. KISS. Robert > > -- > To unsubscribe from this list, just send an email to > [EMAIL PROTECTED] with unsubscribe as the subject. > > -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
