[BUG] Set>>collect:

Bill Spight bspight at pacbell.net
Mon Feb 17 01:13:43 UTC 2003


Dear Richard,

> I wrote:
> 
>         > The essential point about #collect: is that the transformation block
>         > does NOT in general return objects of the same type that it is passed.
> 
> The context here is
>     aCollection collect: whateverBlockTheProgrammerWants
> 
> Bill Spight <bspight at pacbell.net> wrote:
> 
>         Well, in Squeak it seems to, in general. There are a few exceptions.
>         
> I find this response puzzling.  _In Squeak_ itself is not the issue.
> #collect: is for other programmers to use.
> 

I was unclear, and it seems that we are talking about different things.
I intended to talk about the pragmatics of language, i. e., about
interpretation, not about what a programmer might want to do. And in
that regard, Squeak is very much the issue, since it is the Squeak that
the programmer must interpret.

>         As for the case of the code in Set, Set in Squeak has 4 children:
>         Dictionary, Identity Set, Pluggable Set, and Weak Set. Dictionary and
>         Weak Set override collect: So the question comes down to Pluggable Set
>         vs. Identity Set. If it is desirable to have PluggableSet>>collect:
>         create a Set rather than a Pluggable Set, can't you take care of it in
>         PluggableSet, and leave the general behavior the same in both Set and
>         IdentitySet?
>         
> Yes, but the general behaviour we *WANT* for IdentitySet is precisely
> the general behaviour we have *NOW*.
[snip, *not* mentioning IndentitySet.]

> So we see that the reason that there _is_ a Set>>collect: in the first place
> appears to be precisely in order to AVOID using 'self species new'.  It's a
> bug avoidance measure.  I have explained what the bug is.
> 

I take it you are referring to the behavior of PluggableSet, in your
note of a few days ago.

> The point is that having IdentitySet>>collect: return an IdentitySet
> would be simply WRONG in many, if not most, cases.
> 

In many cases, certainly, but it would be right in many cases, as well.

>         Isn't this also to some extent a question of documentation?
> 
> Everything is to _some_ extent a question of documentation.
> The question is "who bears the burden"?
> 
>         The general rule is set out in the comment in Collection.
> 
> Set out rather unclearly, yes.  But you must on no account press that
> little non-technical word "like" too hard.  Anything more than "ordered
> if the receiver is ordered, unordered if the receiver is unordered" would
> be more than it could bear.

I disagree, on the basis of pragmatics. However, I do not think that a
philosophical discussion would do much good here, even if you and I
found it interesting. :-)

The key point, I think, is that if performing collect: on an IdentitySet
produces a Set, you may lose elements that are equal but not
identitical, and recovery is not easy. OTOH, if it includes elements
that are identical but not equal, you can easily convert the resultant
IdentitySet to a Set. (There may be better ways to do it, OC.)

>         It would be reasonable to
>         add to that comment that 3 collections are exceptions: Dictionary,
>         SortedCollection, and PluggableSet.
> 
> They are by no means the only "exceptions".  IdentitySet clear has to be
> one of the so-called "exceptions" too, and there are others.  I repeat,
> you must not press that little word "like" too hard.  A Set is arguably
> LIKE an IdentitySet.

Yes, but the difference, if you are using an IdentitySet in the first
place, is crucial. You are using an IdentitySet because you do *not*
want to test for equality. As for the new collection, who knows, but if
avoiding equality testing was important in the first place, it is
probably still important. We may not even want the new collection to be
a Set, but if we do, it seems to me that it's a good bet that we want it
to be another IdentitySet. Besides the question of probability is that
of prominence, and the idea of avoiding equality testing is still
prominent. 

> IdentitySet is best regarded as a special case of PluggableSet

I beg your pardon? OK, I think I see your point, if you consider
identity to be a kind of equality. But the point of IdentitySet, it
seems to me, is that identity is *more general* than equality. Identity
entails equality, but not the other way around. I know that heredity in
Smalltalk is based on behavior, but logically, Identity should be a
superclass of Set (and the differences in behavior are not that great).

> Set makes sense as result for IdentitySet>>collect:.
> 

It does. But IdentitySet makes more sense. :-)

Best regards,

Bill



More information about the Squeak-dev mailing list