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