Libraries

[Michael David WINIKOFF]

> 
> > Hi!
> > 
> > I think that having the seperate concepts of module, library and object 
> > is overkill. Can't we merge these into a single concept and simplify life?
> > 
> > Michael
> 
> I think the reason I came up with these concepts in the first place had to
> deal with what was being loaded into memory at one time.  Objects tend to be
> small, and if they were each loaded seperately, linking would be hell and
> take up lots of overhead.  The concept of a module is to put into a single
> unit a group of related objects *and* functions *and* data (not just objects).

You mean we're having data that is NOT encapsulated in objects? My god,
what will he come up with next? Blasphemy! :-) :-)

Seriously though, if the only reason for separarting objects into libraries
and modules is efficiency then we'd be better off (IMHO) to keep them as one
concept and just take care to make the implementation efficient.

> I can't see doing away with the concept of a library - our system stuff itself
> may need 20 to 30 modules, the GUI may need 10 or 20, and so on.  Combining
> these into a library simplifies life on disk, so this is a concept important

You're more or less assuming a comventional file-system that doesn't like
small files -- this is not a good thing to assume automatically.

> to the filesystem only.  (A group of files within a file?)  If the *entire*
> system library were loaded at run-time, we'd have the same problem as OS/2
> and Windows - it would take tons of memory to run.  To load only those parts
> necessary, libraries are broken into modules which can be loaded and linked
> to at run-time of an application.  If an app runs and the module exists in
> memory already, no load is necessary.  (Just like DLLs, just different names.)
> Only those portions used by a program are loaded, at run-time.

i think it's simpler just to have objects and to let the virtual memory system
handle loading.

Do you think this is unworkable from an efficiency view?

> 
> In this scheme, a program *is* a module with (in C terminology) a "main"
> function to be called once the program is loaded.
> 
> Again, if objects are loaded individually the overhead would be tremendous -
> if the entire OS or GUI is put in a single module, memory usage would be
> outrageous.

Not with virtual memory.

> 
> I think some of you were asking why not make modules and programs objects?
> This would be nice, except who would benefit?  The only entity responsible
> for (and allowed to) manipulate modules is the kernel.  Nobody else needs
> really any interface at all to modules except information gathering for
> linking purposes. It's really a toss up - it's a nice convention to make
> everything an object, but it may not be useful.  We'll see!
> 
> 			Dennis
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.