At 12:03 PM 27/04/98 -0700, Mike wrote:
>	[Set subclass: #Class]
...............
>
>Now let's look at unifying Class and Set.  Let's ignore the fact that
>Smalltalk's Sets are vastly different from math's sets.
>
>Should the method Class >># do: action
>a)	self allInstances do: action
>b)	self allInstances, allSubinstances do: action
>
>The "natural" answer to this, of course, depends on what we are using 
>the subclassing mechanism to accomplish, as mentioned in Alan Kay's
>earlier post.  Inheritence for implementation wants (a), inheritence for
>specialization wants (b).
>Some people even view abstract classes as "made up" of their subclasses, so
>c)	self allSubclasses do: action
>

Since Class being a Set is a specialization I think there is only one
"natural"
answer (b)


>
>
>Also, it may make sense for a class to represent all posible
>instantiations, not only one's presently in the object memory.
>I.e.  
>	Integer includes: 10000000000000
>=>	true
>

By the time the Integer class checks if 10000000000000 is anInteger,
10000000000000 is an instantiation in memory (or it should be)

>	Integer size
>=>	AlephNull
>

To be consistent with the #do: issue, Integer size should not be null. We know
that we only deal with finite sets, we can take advantage of this knowledge,
which is not just an implementation detail.
It is true that SmallInteger does expose an implementation trick, but it is
a "bad"
class anyway and we should get rid of it.

...................
>and this leads one off into the same pink areas of convenience that making
>
>	'10' asInteger = 10
>or even
>	'10' = 10
>
>seem so attracive.
>(I'll admit to hacking the former, but not the later :-)

I will also admit to have hacked
	#'' isNil = true


>Basicly what we are doing is pressing classes into service of an area that
>we already have good mechanisms for, the Collection hierarchy.
>

I think there is room for improvement even in these good mechanisms:

For example, we can define orders not only for SortedCollections.

Furthermore, a slight generalization of order, where instead of antisimetry
we have a>=b and b>=a implies aEb, with E an equivalence relationship instead
of identity would allow us to sort based on hash for example (hash defines an
equivalence) and to use the hash to test more efficiently for inclusion.

And if we "parametrize" the Collection classes based on a decoupled
equivalence
relation used to test for inclusion we can simplify the hierarchy: no more
Identity... classes, less code redundancy and more generality: we could
use many arbitray equivalence relations, not just #== and #=.

Cheers,

Florin