From: David Simmons Date: 2002-02-14T15:38:39+09:00 Subject: Modules and Interface Protocols [Was: type check and dynamic binding] "Michael Lucas-Smith" wrote in message news:3C6B4A9F.E09246E7@wizardis.com.au... > 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 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 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 > > 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 and share *no* superclasses in common. But > > they do share supertypes in common; specifically . > > > > -- 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