Quite some software (Seaside, Mondrian, Magritte, Pier, ...) depends
on the current implementation of #copyFrom:, as it is an extremely
efficient way to remember and restore the state of an object:
rememberReceiverDuring: aBlock
previous := self shallowCopy.
^ aBlock ensure: [ self copyFrom: previous ]
I don't think that the name of #copyFrom: is misleading (it derives
from #copy). What you are looking for is #allButFirst: that goes along
with #allButFirst, #allButLast:, allButLast, #first:, and #last:.
Cheers,
Lukas
On 1 January 2011 19:39, Schwab,Wilhelm K <[email protected]> wrote:
> Wow. In fairness, Dolphin has one or two such oddities. IIRC, the confusion
> there is that external arrays (DOUBLE, DWORD, etc.) respond to #copyFrom:to:
> in terms of bytes, not elements.
>
> The problem in this case appears to be that
>
> 'a string with some stuff in it' copyFrom:5
>
> should blow up because 5 is not a suitable source (a string of some type)
> from which to copy a string's state. Once it properly reports abuse, we can
> then move on to asking whether we want a copying selector that can be so
> easily confused with copying from an index. It might be better named
> #copyStateFrom:??
>
> Sorry to beat the usual drum, but it fits: silent failures need to be hunted
> down and killed.
>
> Bill
>
>
>
> ________________________________________
> From: [email protected]
> [[email protected]] On Behalf Of Stéphane Ducasse
> [[email protected]]
> Sent: Saturday, January 01, 2011 1:29 PM
> To: [email protected]
> Subject: Re: [Pharo-project] An intuitive (or screwed) #copyFrom:
>
> HI sebastian
>
> If I remember correctly you are not the only one bitten by it :) so we should
> do something
>
> Object>>copyFrom: anotherObject
> "Copy to myself all instance variables I have in common with
> anotherObject. This is dangerous because it ignores an object's control over
> its own inst vars. "
>
> Now you enumeration is too complex for me :)
>
>> I ask because, if so, situation goes like this:
>>
>> A. we think again and decide to do the right thing or we go with the
>> alternative which is
>> B. we leave it as invalid, as it is right now, and
>> 1. we mislead even to smalltalkers not familiarized to squeak/pharo
>> 2. we rationalize some clever way to see it as a feature even if it
>> will mislead everybody (even ourselves in a hurry)
>> 3. we lay a foundation to lightly use protocol that is typically used
>> in collections (to do dangerous things like instVar manipulation)
>> 4. we break encapsulation and manipulate extremely primitive things in
>> a common sounding selector.
>> 5. we work harder on trying to give the impression that we're leaving
>> it like that because we're smarter than the confused people that tried to
>> use it (proving to them that we're dumb)
>> 6. we get involved in an unnecessarily complicated way of thinking
>> that will complicate unnecessarily our future (guaranteed)
>> 7. we learn how to maintain a screwed attitude in front of people
>> trying to use intuition when using pharo
>> 8. we stay comfortable (on the wrong foundation and for the wrong
>> reasons)
>>
>> That would leave us with this question in the table:
>>
>> what is compatible with the Pharo's mission? is it A or B?
>
> My state of mind is always to make the world better :)
>
> Now
> - did you check the senders to copyFrom:?
> sounds ok not so many so we could deprecated it easily
>
> - did you check in other Smalltalk if this method is used or not?
> VW not in Object but in probe something
>
> - did you check the ansi standard?
> I guess that this is not there.
>
> The finder says:
> 'if this isn''t broken' . 15 . 'broken'
>
> no single method, strange.... but indeed
> 'if this isn''t broken' . 15 . 20 . 'broken' find copyFrom:to:
>
> Now what would be a better name
>
> copyFromObject:
>
> then
>
> on String>>copyFrom: ?
>
> Even if I would prefer (but it sucks) String>>copyFromIndex: but this is
> more coherent with copyFrom: index to: another
>
>
> Stef
>
>
>
>
--
Lukas Renggli
www.lukas-renggli.ch
