Re: polymophism

[donh@syd.csa.com.au (Don Harrison)]

Joachim Durchholz writes:

:donh@syd.csa.com.au wrote 25.11.96:
:
:> You may be thinking of clusters (which aren't part of the language). These
:> serve only to group classes into subsystems as an administrative convenience
:> and have no semantic significance.
:
:Though clusters have been declared not to be part of the language, they  
:really are.
:After all, it is the *compiler* that declares an error if it can't find a  
:class because it has been renamed via cluster configuration.

Yes, renaming clauses in clusters *do* consitute part of the 'program'
and convey essential semantics. I stand corrected. Such renaming effectively
de-overloads class names.

:Besides, I don't feel quite at home with the class = module requirement.  

I think this is still okay so long as you define a facade class, where 
needed, to provide a common interface to a cluster of classes. This delivers 
the scalability needed for large systems.

:There are useful libraries that consist of dozens of tiny classes, some  
:containing nothing more than a few invariant or constant definitions.   
:Such classes have too fine granularity to allow easy understanding of a  
:system; you need larger units. 

Agree.

I think the Cluster concept fill that gap  
:(and quite well, too).

Agree (if used with facades). What Eiffel does *not* need (and can do 
without), IMO, is a package/namespace mechanism. Clusters are a more flexible 
solution for Eiffel because they contain only configuration information and 
are defined in separate files to classes. Consequently, clusters and classes 
can be changed independently and moving class texts is not necessary to 
include/exclude them.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au