inferno is a bit more clever. only the used functions from a load of Sys are required. everything is a module, tho many modules are apps that can be run from whatever shell. the code, if it be jitted or not, is shared. the module data is copied. i like it.
strong type checking rules. and it achieves the goal of making apps tiny. brucee On 4/19/06, Michael Baldwin <[EMAIL PROTECTED]> wrote: > > the boundary is a bit blurred on inferno, because the explicitly > > module loading there is most commonly used to load what on other > > systems would be libraries. but the result, at least as > > implemented, has a very different feel from the shared library hell > > on unix and windows. > > Aren't some of the same maintenance and versioning headaches > associated with shared libraries still there with dynamic loading of > modules? In Inferno, occasionally the Sys module changes (just to > pick a nasty one), and that can wreak similar havoc as incompatible > shared libraries unless you have a flag day. I've pondered playing > with the PATH string in a module header to make this less burdensome, > but I haven't seen anyone actually do it or even talk to the issue > (OK, there aren't that (m)any users of Inferno to have people to ask, > I know). > > It just seems that, if for some reason I go and change a function > signature in the String module, say, isn't it a similar headache as > shared libraries to keep all the programs that use the old and new > module running and happy at the same time? I know merely adding > functions is still compatible, but sometimes incompatible changes > must be made (int->big for file sizes and offsets comes to mind). > And to keep old and new programs not just running but compiling is a > bit of a bitch. Has anyone thought about or addressed these issues > in Inferno or another dynamic-loading system? Any lessons that can > be learned and brought back to the unwashed world of shared libraries? > >
