Namespaces - Importing versus Explicit Naming (was Re: [Modules] Upper

David Simmons David.Simmons at smallscript.com
Wed Feb 20 21:16:07 UTC 2002


On the subject of namespaces and modules...

SmallScript provides for both inheritance and explicit import of
namespaces. It also provides for import of specific namespace entities
via aliasing. Where in the latter case, you can import an item from some
other namespace, and rename it (or give it the same name) within the
local namespace.

This pattern is very important because explicit "pathing" of names is
verbose, fragile, and can make code significantly harder to understand.

SmallScript allows you to provide paths, including and/or only using the
strong UUID name. But it is rare/infrequent, and mostly occurs for
explicit imports between one namespace and another.

SmallScript distinguishes the notion of "include" for source code, from
the concept of "access" to a elements of a code module.

    Include path: ...

    Requires module: ...

    Load module: ...

These are important semantics to distinguish. Where a "source" chunk
maybe included multiple times and can behave like a simple macro form.

The distinction between "requiring" a module, and just "loading" it has
to do with pre-requisites on the module that is making the reference. 

Specifically, requiring a module will ensure it is a pre-requisite even
if no other code in the current module makes use of any aspect of the
"required" module.

Whereas, "loading" a module just makes it available for binding during
the "resolve" process of building the current module.

This is principally of value for the case where you have dynamically
evaluated code that will make use of the given "required" module at
runtime, or for those cases where the required module modifies the
behavior of various aspects of the system even though it does not
directly contain "elements" that are referenced by the current module.

Put another way, to merely load a module, is to just make available its
exported elements for static linking/reference during a module build
process. If no reference exist to a "loaded" module within the module
being built, then the module being built will not "require" the "loaded"
module.

-- Dave S. [SmallScript Corp]

SmallScript for the AOS & .NET Platforms
David.Simmons at SmallScript.com | http://www.smallscript.org


> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org [mailto:squeak-dev-
> admin at lists.squeakfoundation.org] On Behalf Of Cees de Groot
> Sent: Tuesday, February 19, 2002 11:40 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Namespaces - Importing versus Explicit Naming (was Re:
> [Modules] Upper
> 
> Doug Way <dway at riskmetrics.com> said:
> >The Java project I'm working on strictly uses approach B.  There are
*no*
> duplicate classnames among 1000 or so classes across many packages in
the
> app.  A few imported classnames from other frameworks conflict, but
very
> rarely.  (Two different external packages each had their own
> implementation of a Date object, which was confusing.)
> >
> Just to add a data point: in my current VW project, with some 400
classes
> and
> no 'thou shall not make up duplicate names' rule, we have one
duplicate
> name
> and that has attended us to the fact that the name in fact was a bad
name
> for
> both classes (FooBarProcessor, 'Processor' being much too
> abstract/generic/whatever). In Java, I used to have similar metrics.
> 
> So I agree that IRL, duplicate names are not a big issue and unit
tests
> will
> quickly uncover any mix-ups.
> 
> --
> Cees de Groot               http://www.cdegroot.com
<cg at cdegroot.com>
> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098
9E8B





More information about the Squeak-dev mailing list