[squeak-dev] asX message sent of object of type X

Levente Uzonyi leves at elte.hu
Tue May 10 21:12:44 UTC 2011


On Tue, 10 May 2011, Ralph Boland wrote:

> Earlier I posted on the fact that  asSortedCollection when sent to an instance
> of SortedCollection returns a copy of the receiver rather than the receiver.
> I threatened to generate a bug report but based upon the feedback I have
> decided not to as I have been convinced it would not be a good idea.
> Thanks to all for the feedback.
>
> As it stands for some classes X  asX  returns the receiver and for other classes
> a copy of the receiver is returned with no apparent reason for
> choosing one over the other.
>
> Now, if I create a new class Y  and a method  asY,  should I
>  a) always return the receiver
>  b) always return a copy of the receiver
>  c) sometimes do a) and other times do b).
>
> If the answer is c) then the guidelines for choosing are?

I prefer a). So Foo >> #asFoo is simply ^self, Object >> #asFoo is 
something like ^Foo newFrom: self. If you want to create a copy of the 
receiver even if it's an instance of Foo, then you can use #as:, e.g.: 
anObject as: Foo.

>
> Regards,
>
> Ralph Boland
>
> ps.  Adding my two cents worth: the "as" part of "asY" suggests some
> kind of conversion.
> Thus a copy should be made even when no conversion is done.  One
> should be able to
> depend upon the object returned being a copy.
> If a conversion is to be done only when necessary then some other
> method should be
> invoked.  The best (not very good) name I could come up with for such
> a method is:
>  toX
> If nothing else, having two different names for the two different
> actions is a good idea.
> As pointed out, for existing classes we are stuck with the status quo
> for backward
> compatibility reasons.  I guess compatibility with other Smalltalks is
> also an issue.

I'd like to have #asOrderedCollection, #asSortedCollection and 
#asCharacterSet returning the receiver if it's already the instance of the 
named class. It's not backwards compatibility what stops me to add these 
methods, but the fact that adding these would result in silent errors in 
code which relies on the copy creation.


Levente

>
>



More information about the Squeak-dev mailing list