[Prev][Next][Index][Thread]

Re: A basic question: defining modules and libraries

"James" <james@openscript.com> wrote in message
38DAA0F4.C62AD810@openscript.com">news:38DAA0F4.C62AD810@openscript.com...
> I'll try to field this one. Basically, Dylan provides
> Libraries and Modules as a way of managing namespace.

I think this is only part of the picture.  Libraries are the units of
namespace control in Dylan, but modules seem to be more the unit of
encapsulation.  As such Dylan modules are more closely related to classes in
C++ or Java than they are to C++ namespaces or Java packages.

Another way to look at this would be to take Lakos' approach to C++ with
"components" and "packages".  In Lakos' terms of physical design, a
component is a group of cooperating classes which provides a service to the
outside through its public interface (which can include several classes).
If you need friends, etc. they belong in the same component.  Thus in Lakos'
approach, components are the fundamental unit of encapsulation and access
control.

Packages are groups of components which offer interlocking suites of
functionality.  A package would generally be a (possibly third-party)
library.  In the Windows world a package is typically a .LIB or .DLL file,
for example.  They are thus a unit of linkage (not compilation) as well as a
convenient set of components bundled together for use.

I kind of picture Dylan's approach to things this way.  Modules are Lakos'
components and are thus the unit of encapsulation and the public interface
to a batch of code.  Libraries are Lakos' packages and are thus the unit of
delivery and linkage.

If I'm wrong on this, I'm sure some of the Dylan regulars will swat me in my
place.  :-)  (I'm somewhat of a Dylan newbie myself.)
References: