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

[REBOL] Re: DLL Hell = Rebol library script version

From: maximo:meteorstudios at: 13-Nov-2003 11:19

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.