[Pharo-project] An intuitive (or screwed) #copyFrom:

csrabak at bol.com.br csrabak at bol.com.br
Sat Jan 1 19:33:13 EST 2011


I would like to add to the tally. Changing Object>>copyFrom: to Object>>copyStateFrom: makes for me a lot more sense that changing (in fact by the creation of) OrderedCollection>>copyFrom: to OrderedCollection>>copyFromIndex:

Except we do agree /in limine/ that OrderedCollection>>copyFrom:to: should be changed to
OrederedCollection>>copyFromIndex:toEndIndex: 
 




Em 01/01/2011 17:48, Schwab,Wilhelm K < bschwab at anest.ufl.edu > escreveu:
Lukas,

I must respectfully disagree: it is also quite similar to #copyFrom:to:, and behaves *completely* differently from same.  #copyFrom: really should have a more intention-revealing name.

Bill



________________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli at gmail.com]
Sent: Saturday, January 01, 2011 2:06 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

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  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: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse at inria.fr]
> Sent: Saturday, January 01, 2011 1:29 PM
> To: Pharo-project at lists.gforge.inria.fr
> 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







More information about the Pharo-dev mailing list