2011/5/10 Levente Uzonyi <leves at elte.hu>:
> 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.
>

I noted once than #as: always creates a copy

| a |
a := #(1 2 3).
b := a as: a class.
b ~~ a

>>
>> 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.
>

The difference with backward compatibility must be too subtle for me
to understand :)

Nicolas

>
> Levente
>
>>
>>
>
>