Modules and Interface Protocols [Was: type check and dynamic binding]

"Michael Lucas-Smith" <[e-mail]> wrote in message
news:[e-mail]...
> So effectively, an interface acts as a module as in Ruby + a formal
interface
> definition.

I am not expert enough in Ruby's implementation to fully understand what its
"module" imply. On the surface, your statement is correct.

SmallScript also has the concept of "module" and the use of the term in the
Ruby context is boggling my brain slightly [but then again, I'm kind of
hungry so maybe its just a blood sugar thing].

In SmallScript:

A module is a "unit" of deployment and packaging for binary distribution and
loading. It therefore serves as a "unit" of (packaging/loading) ownership
for any bindable/scopeable elements.

A scope (namespace) is a "unit" of priviledge and encapsulation. It
determines what is or is not visible/accessible from a particular context.

An interface is a "unit" of shareable/re-useable behavior, and serves as a
first class representation for both an implementation of, and the semantics
for, a protocol contract.

Like any <Behavior> type, an interface defines a collection of methods that
a given type of object has available. For a given object type, the set of
all its "behaviors" (types) collectively determine its set of "available"
methods. Noting that the set of applicable accessible methods is a subset of
the available methods. Each method additionally specifies various binding
predicates that determine runtime scoping-priviledge/access and the binding
priority of one method relative any other available methods.

A class is a type of behavior, as are metaclass, etc. Types are classes.
Interfaces are special kind of class. Namespaces are classes. Modules are
classes that implement module interface semantics [typically this would be
for projects, applications, components, and libraries].

Namespaces binding priviledge/scope is a distinct/orthogonal concept to that
of packaging/ownership. Thus one can define a module X and a module Y. Both
of which contain/own elements which are defined within Z namespace.

Because a module is a class, and classes are namespaces, the module may also
serve as a single entity for both roles. But the roles of namespace unit and
module/deployment unit are distinct.

The object model defines strong-names for all <Behavior> entities. Where a
strong name is a UUID that has universal identity. The strong-names
therefore define fixed length unique identity for any given behavioral
(namespace/module/etc) entity. This eliminates classic package and module
problems with pathing, or ambiguities resulting from human naming or
renaming patterns.

Modules contain references as both paths, and strong-names. When a module is
loaded its set of external module pre-requisites are examined. From that the
set of module pre-requiste uuid's are examined. Those uuid's are then used
to unambiguously locate the require external modules as constrained by
version pre-requisites for a given module.

This mechanism eliminates disk related path concerns and provides the
architecture for modules to be loaded/obtained from network as well as local
media stores. I.e., the UUID and other signature information in the module
enable generation of standard URL/URI for use in locating a module. Modules
are installed on a machine and detected automatically (or explicitly) by the
runtime architecture.

When a module is loaded it may create/load methods, variables, etc and
thereby alter classes (or any other behavior). Every change it makes is
"owned" by the module. Which allows efficient unloading and ensures that
dynamic changes throughout the system can be tracked for subsequent updating
of the module into new versions [synonomous with classic Smalltalk notions
of image snapshots, but at a module level of granularity].

Does this help?

-- Dave S. [www.smallscript.org]

>
> David Simmons wrote:
>
> > I realize the previous posts declaration example did not sufficiently
> > illustrate the superclass vs interface distinctions for those not
familiar
> > with the SmallScript AML syntax. So here is a slightly more extended
> > example:
> >
> >     Interface name: ICollection {
> >         ...generic method implementations here...
> >     }
> >     Class name: MyThing extends: MySuperClass
> >         implements: ICollection
> >     {
> >         ...maybe *no* collection related methods here
> >            if the default implementations in <ICollection>
> >            provided all the necessary behavior. Unlike
> >            languages such as Java with only abstract
> >            interfaces, we can maximize re-use through
> >            the design and implementation of behavior
> >            directly in interfaces. Allowing classes to
> >            override or extend those default implementations...
> >     }
> >
> >     Class name: AnotherThing extends: AnUnrelatedSuperclass
> >         implements: ICollection.
> >
> > We can then ask:
> >
> >     aMyThing isKindOf: ICollection. "will answer true"
> >
> >     AnotherThing isKindOf: ICollection. "will also answer true"
> >
> > Where <MyThing> and <AnotherThing> share *no* superclasses in common.
But
> > they do share supertypes in common; specifically <ICollection>.
> >
> > -- Dave S. [www.smallscript.org]
> >
>


begin 666 Dave Simmons.vcf
M0D5'24XZ5D-!4D0-"E9%4E-)3TXZ,BXQ#0I..E-I;6UO;G,[1&%V:60[00T*
M1DXZ1&%V92!3:6UM;VYS#0I.24-+3D%-13I$879E(%,N#0I/4D<Z4VUA;&Q3
M8W)I<'0@3$Q##0I54DP[5T]22SIH='1P.B\O=W=W+G-M86QL<V-R:7!T+F]R
M9PT*14U!24P[4%)%1CM)3E1%4DY%5#ID879I9"YS:6UM;VYS0'-M86QL<V-R
J:7!T+F-O;0T*4D56.C(P,#(P,C$T5# V,#$R,%H-"D5.1#I60T%21 T*
`
end