Modules instead of Behaviors (was: Generalized Object Modules Design)

Richard A. O'Keefe ok at cs.otago.ac.nz
Tue Mar 5 23:49:50 UTC 2002


Anthony Hannan <ajh18 at cornell.edu> wrote:
		A module is a group of related methods from many classes that fullfill
	a single functionality.  A module is equivalent to a method category
	like 'printing' which may cross many classes.  All methods in 'printing'
	from all classes would end up in a single module called 'Printing'.

I don't propose to comment on the rest of his proposal.

But this claim is clearly wrong.
If I have some XML classes (and I do), and I have methods for
printing (and I do), they are primarily *about* XML, not *about* printing.
If you loaded the XML classes, you might or might not want the printing
methods; arguably one could chop an XML package up along
common/parsing/printing/visiting lines, with parsing, printing, and
visiting optional.
But if you loaded the "Printing" module in order to print plain text,
you _wouldn't_ want the XML printing methods loaded as well.

We can classify a method several ways:
    - what class does it belong to?
    - what encapsulation boundary/namespace does it live in?
    - what other methods should it be loaded with?
    - which of several syntaxes does it use?
    - who wrote it/who has permission to revise it?
    - which use cases is this needed for?
    - what kind of action does this perform?
    ...

Bertrand Meyer argued for years that classes should be used for
everything, and then Eiffel acquired a notion of "cluster" (more or
less a unit of linking) in its configuration language Lace.
Ada and Common Lisp drive a wedge between classes and packages (which
are encapsulation boundaries), Lisp drives a wedge between both and
units of loading; units of loading can be bigger _or_ smaller than
classes, bigger _or_ smaller than packages.

Because there are many ways to classify fragments of code, it is
unlikely that a single mechanism can serve well for all of them.
While a single mechanism can be very useful for what it does, I
think it unlikely that a mechanism designed without at least
_considering_ the other ways of classifying and structuring will
have staying power.



More information about the Squeak-dev mailing list