Diff for ObjectSpaces' guide

Tue, 10/26/2010 - 18:27 by Gwenael CasaccioTue, 10/26/2010 - 18:57 by Gwenael Casaccio
Changes to Body
Line 35 Line 35
The way to create classes in Smalltalk: The way to create classes in Smalltalk:
 +<pre>
Object subclass: #File Object subclass: #File
instanceVariableNames: 'directory fileId name' instanceVariableNames: 'directory fileId name'
classVariableNames: 'PageSize' classVariableNames: 'PageSize'
poolDictionaries: 'CharacterConstants' poolDictionaries: 'CharacterConstants'
 +</pre>
 +
They create a new module: They create a new module:
 +<pre>
Object moduleSubclass: #InventoryManager Object moduleSubclass: #InventoryManager
instanceVariableNames: '' instanceVariableNames: ''
classVariableNames: '' classVariableNames: ''
poolDictionaries: '' poolDictionaries: ''
 +</pre>
 +
Add a private class in the domain: Add a private class in the domain:
 +<pre>
Object subclass: #InventoryItem in: #InventoryManager Object subclass: #InventoryItem in: #InventoryManager
instanceVariableNames: 'partNumber partName quantity' instanceVariableNames: 'partNumber partName quantity'
classVariableNames: '' classVariableNames: ''
poolDictionaries: '' poolDictionaries: ''
 +</pre>
===== Encapsulating Private Behavior ===== ===== Encapsulating Private Behavior =====
Line 64 Line 72
Modules provide a safe way to extend and package changes to the baseline classes in the Smalltalk system domain. Modules provide a safe way to extend and package changes to the baseline classes in the Smalltalk system domain.
 +<pre>
Object moduleSubclass: #ModuleA Object moduleSubclass: #ModuleA
instanceVariableNames: '' instanceVariableNames: ''
classVariableNames: '' classVariableNames: ''
poolDictionaries: '' poolDictionaries: ''
 +</pre>
 +
 +<pre>
Object subclass: #SubclassB in: #ModuleA Object subclass: #SubclassB in: #ModuleA
instanceVariableNames: '' instanceVariableNames: ''
classVariableNames: '' classVariableNames: ''
poolDictionaries: '' poolDictionaries: ''
 +</pre>
 +
 +<pre>
String subclass: #String in: #ModuleA String subclass: #String in: #ModuleA
instanceVariableNames: '' instanceVariableNames: ''
classVariableNames: '' classVariableNames: ''
poolDictionaries: '' poolDictionaries: ''
 +</pre>
 +
The private String class extensions are visible to methods in both ModuleA and SubclassB, but not to classes outside of ModuleA in the Smalltalk system domain. The private String class extensions are visible to methods in both ModuleA and SubclassB, but not to classes outside of ModuleA in the Smalltalk system domain.
Line 84 Line 101
Modules can be used to hide the private methods of a class. To do this, a public module is created with the public interface and the private method are hidden inside a private class inside the public domain. Modules can be used to hide the private methods of a class. To do this, a public module is created with the public interface and the private method are hidden inside a private class inside the public domain.
 +<pre>
Object moduleSubclass: #ClassA Object moduleSubclass: #ClassA
instanceVariableNames: 'privateSelf' instanceVariableNames: 'privateSelf'
classVariableNames: '' classVariableNames: ''
poolDictionaries: '' poolDictionaries: ''
 +</pre>
 +
 +<pre>
Object subclass: #ClassA in: #ClassA Object subclass: #ClassA in: #ClassA
instanceVariableNames: '' instanceVariableNames: ''
classVariableNames: '' classVariableNames: ''
poolDictionaries: '' poolDictionaries: ''
 +</pre>
 +
The ClassA module has a single instance variable: privateSelf. This is a simple proxy that hides the private behavior of the module class, all the messages are delegated to privateSelf. The ClassA module has a single instance variable: privateSelf. This is a simple proxy that hides the private behavior of the module class, all the messages are delegated to privateSelf.
Line 130 Line 153
Classes are globals in Smalltalk, they are all visible to all other classes, this is excessive. Classes are globals in Smalltalk, they are all visible to all other classes, this is excessive.
 +<pre>
SomeSuperclass subsystem: #SomeSubsystem SomeSuperclass subsystem: #SomeSubsystem
instanceVariableNames: '' instanceVariableNames: ''
classVariableNames: '' classVariableNames: ''
poolDictionaries: '' poolDictionaries: ''
 +</pre>
 +
 +<pre>
AnotherSuperclass subsystem: #SomePrivateClass in: #SomeSubsystem AnotherSuperclass subsystem: #SomePrivateClass in: #SomeSubsystem
instanceVariableNames: '' instanceVariableNames: ''
classVariableNames: '' classVariableNames: ''
poolDictionaries: '' poolDictionaries: ''
 +</pre>
 +
 +<pre>
SomeSubsystem @ #SomePrivateClass subclass: #SomePrivateSubclass SomeSubsystem @ #SomePrivateClass subclass: #SomePrivateSubclass
instanceVariableNames: '' instanceVariableNames: ''
classVariableNames: '' classVariableNames: ''
poolDictionaries: '' poolDictionaries: ''
 +</pre>
 +
 +<pre>
SomeSubsystem @ #SomePrivateClass subsystem: #SomePrivateSubsystem SomeSubsystem @ #SomePrivateClass subsystem: #SomePrivateSubsystem
instanceVariableNames: '' instanceVariableNames: ''
classVariableNames: '' classVariableNames: ''
poolDictionaries: '' poolDictionaries: ''
 +</pre>
 +
The binary symbol @ is used as a scope resolution operator. The binary symbol @ is used as a scope resolution operator.
Line 151 Line 186
In Smalltalk all the methods of a class are effectively public. Smalltalk developer indicates that a method is private by setting the category as private. In Smalltalk all the methods of a class are effectively public. Smalltalk developer indicates that a method is private by setting the category as private.
-Access Implied Client Specification +
-Private Only the implementing class +
-Protected The implementing class and all derived classes +<pre>
-Promised Some specific collaborating class + Access Implied Client Specification
-Public Any class + Private Only the implementing class
 + Protected The implementing class and all derived classes
 + Promised Some specific collaborating class
 + Public Any class
 +</pre>
 +
The classes that collaborate closely with a subsystem often exhibit promised behavior. Thus, it would be advantageous to object system designer if object languages incorporated and enforced access mechanisms based on client specification to establish such formal contracts. Private, protected and public access can be conceived as specific kinds of promised contracts in the following manner. The classes that collaborate closely with a subsystem often exhibit promised behavior. Thus, it would be advantageous to object system designer if object languages incorporated and enforced access mechanisms based on client specification to establish such formal contracts. Private, protected and public access can be conceived as specific kinds of promised contracts in the following manner.
-Access Equivalent Contract +<pre>
-ServerClass private ServerClass promisedTo: ServerClass only + Access Equivalent Contract
-ServerClass protected ServerClass promisedTo: ServerClass any + ServerClass private ServerClass promisedTo: ServerClass only
-ServerClass public ServerClass promisedTo: nil + ServerClass protected ServerClass promisedTo: ServerClass any
 + ServerClass public ServerClass promisedTo: nil
 +</pre>
 +
nil is used because all the root classes are derived from nil. nil is used because all the root classes are derived from nil.
Line 170 Line 213
Bibliography Bibliography
-1 Class naming and privacy in smalltalk. +# Class naming and privacy in smalltalk www.educery.com/papers/subsys/subsys.htm
-2 Modules: Encapsulating behavior in smalltalk. +# Modules: Encapsulating behavior in smalltalk http://www.educery.com/papers/modules/

Revision of Tue, 10/26/2010 - 18:57:

ObjectSpaces' guide

Introduction

ObjectSpaces are group of objects with a global environment and their own memory area.
ObjectSpaces are organized in a n-tree thus an ObjectSpace has one parent and zero or ore children.

An object belongs to one and only one ObjectSpace. The reflection is restricted to the current ObjectSpace an object couldn't inject an object in an instance variable to a external object, or swap references of two objects that don't belong to the current ObjectSpace

Modules

Abstract of modules papers

Modules: Encapsulating Behavior in Smalltalk

This article proposes a new view of modules - this is done in Smalltalk. Modules are a way to control the visibility of shared names. Modules also provide a way to hide the detailed collaborations among a group of Smalltalk classes. Modules can also be used to safely extend existing baseline classes.

Smalltalk can encapsulate the state of their instances, they don't encapsulate the behavior of their instances. Classes are globals in the Smalltalk system dictionary, they are all visible to all other classes.

Definition of Modules

Allen Wirfs-Brock and Brian Wilkerson in Modular Smalltalk describe features of modules:

Modules are program units that manage the visibility and accessibility of names...

A module typically groups a set of classes definitions and objects to implement some service or abstraction. A module will frequently be the unit of division responsibility within a programming team...

A module provides an independent naming environment that is separate from other modules within the program...

Modules support team engineering by providing isolated name...

In Modular Smalltalk modules are not first-class objects. It uses modules only for organizational purposes.

Modules for Smalltalk

The way to create classes in Smalltalk:

Object subclass: #File
  instanceVariableNames: 'directory fileId name'
  classVariableNames: 'PageSize'
  poolDictionaries: 'CharacterConstants'

They create a new module:

Object moduleSubclass: #InventoryManager
  instanceVariableNames: ''
  classVariableNames: ''
  poolDictionaries: ''

Add a private class in the domain:

Object subclass: #InventoryItem in: #InventoryManager
  instanceVariableNames: 'partNumber partName quantity'
  classVariableNames: ''
  poolDictionaries: ''

Encapsulating Private Behavior

Modules provides 3 ways of encapsulating private behavior:

  • Class groups
  • Baseline Class Extensions
  • Private Methods
Extending Baseline Smalltalk Classes

Modules provide a safe way to extend and package changes to the baseline classes in the Smalltalk system domain.

Object moduleSubclass: #ModuleA
  instanceVariableNames: ''
  classVariableNames: ''
  poolDictionaries: ''

Object subclass: #SubclassB in: #ModuleA
  instanceVariableNames: ''
  classVariableNames: ''
  poolDictionaries: ''

String subclass: #String in: #ModuleA
  instanceVariableNames: ''
  classVariableNames: ''
  poolDictionaries: ''

The private String class extensions are visible to methods in both ModuleA and SubclassB, but not to classes outside of ModuleA in the Smalltalk system domain.

One drawback in that example the compiler create literals using the baseline classes: SmallInteger, String, Float, Symbol and Array.

Encapsulating Private Methods

Modules can be used to hide the private methods of a class. To do this, a public module is created with the public interface and the private method are hidden inside a private class inside the public domain.

Object moduleSubclass: #ClassA
  instanceVariableNames: 'privateSelf'
  classVariableNames: ''
  poolDictionaries: ''

Object subclass: #ClassA in: #ClassA
  instanceVariableNames: ''
  classVariableNames: ''
  poolDictionaries: ''

The ClassA module has a single instance variable: privateSelf. This is a simple proxy that hides the private behavior of the module class, all the messages are delegated to privateSelf.

Adding Modules to Smalltalk

A module class uses a ModuleDictionary for its domain, it is similar to the SystemDictionary class. Each class contained inside a module domain is associated with an EncapsulatedMetaClass rather than a MetaClass, it stores a reference to the module.

Resolving Shared Names

The visibility of the names depends on where they are located in the system. Shared names can be found in class variable pools, global pool dictionaries, and the Smalltalk system dictionary. During the method compilation, references to shared names are resolved by searching dictionaries in the following order:

class variable pool of the class and its superclasses.
pool dictionaries to which the class subscribes in the modul domains enclosing to the Smalltalk system domain.
Module domains enclosing the class up through the Smaltalk system domain

Breaking and Enforcing Module Encapsulation

Modules enclose and encapsulate their private classes, the programming tools need a way to break the encapsulation of the module to create a new class inside the module.

The method #doesNotUnderstand: aMessage to see if it is the name of a private class inside the module. This service breaks the encapsulation but it is needed by the compiler and development tools.

In order to enforce the encapsulation of a module, it can be close:

ModuleA closeModule

Module Interfaces

A module can provide an access to a group of private classes, by providing an accessing message as a part of the public interface.

Class Naming and Privacy in Smalltalk

Abstract

Smalltalk lacks mechanisms for defining private classes and private methods. Without private classes, class naming conflicts can occur. Without private methods, encapsulation suffers. While global name spaces can help resolve class naming conflicts, first-class subsystems with private classes can resolve both problems.

The Name Space problem

Classes are globals in Smalltalk, they are all visible to all other classes, this is excessive.

SomeSuperclass subsystem: #SomeSubsystem
  instanceVariableNames: ''
  classVariableNames: ''
  poolDictionaries: ''

AnotherSuperclass subsystem: #SomePrivateClass in: #SomeSubsystem
  instanceVariableNames: ''
  classVariableNames: ''
  poolDictionaries: ''

SomeSubsystem @ #SomePrivateClass subclass: #SomePrivateSubclass
  instanceVariableNames: ''
  classVariableNames: ''
  poolDictionaries: ''

SomeSubsystem @ #SomePrivateClass subsystem: #SomePrivateSubsystem
  instanceVariableNames: ''
  classVariableNames: ''
  poolDictionaries: ''

The binary symbol @ is used as a scope resolution operator.

Private Methods and Client Contracts

In Smalltalk all the methods of a class are effectively public. Smalltalk developer indicates that a method is private by setting the category as private.

  Access    Implied Client Specification
  Private   Only the implementing class
  Protected The implementing class and all derived classes
  Promised  Some specific collaborating class
  Public    Any class

The classes that collaborate closely with a subsystem often exhibit promised behavior. Thus, it would be advantageous to object system designer if object languages incorporated and enforced access mechanisms based on client specification to establish such formal contracts. Private, protected and public access can be conceived as specific kinds of promised contracts in the following manner.

  Access                 Equivalent Contract
  ServerClass private    ServerClass promisedTo: ServerClass only
  ServerClass protected  ServerClass promisedTo: ServerClass any
  ServerClass public     ServerClass promisedTo: nil

nil is used because all the root classes are derived from nil.

Private Methods and Client Contracts

This is mostly the same as the Modules: Encapsulating Behavior in Smalltalk paper. A public module with an instance variable privateSelf and an inner private class. The module provide interface like a proxy to the real instance.

Bibliography

  1. Class naming and privacy in smalltalk www.educery.com/papers/subsys/subsys.htm
  2. Modules: Encapsulating behavior in smalltalk http://www.educery.com/papers/modules/

User login