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
