David L . Nicol <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons wrote:
>
>> We need to distinguish "module", "overlay", "loadable", ... if we are
>> going to get into this type of discussion. Here is my 2¢:
>>
>> Module - separately distributable Perl and/or C code. (e.g. Tk800.022.tar.gz)
>> Loadable - OS loadable binary e.g. Tk.so or Tk.dll
>> Overlay - Tightly coupled ancillary loadable which is no use without
>> its "base" - e.g. Tk/Canvas.so which can only be used
>> when a particular Tk.so has already be loaded.
>
>I know I've got helium Karma around here these days but I don't like
>"overlay" it is reminiscent of old IBM machines swapping parts of the
>program out because there isn't enough core.
Which is exactly why I chose it - the places these things makes sense are
on little machines where memory is a premium.
>Linux modules have
>dependencies on each other and sometimes you have to load the more basic
>ones first or else get symbol-undefined errors. So why not follow
>that lead and call Overlays "dependent modules."
A. Name is too long.
B. That does not have same "feel" as what we have.
>
>If a dependent module knows what it depends on, that module can be
>loaded on demand for the dependent one.
But - like old-style overlays our add-ons are going to be loaded on need
by the parent and only depend on the parent.
e.g. perl discovers it needs to getpwuid() do it loads the thing
that has those functions.
We are not going to be in the middle of getpwuid() and decide we need perl...
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
