On Jan 2, 2011, at 1:33 AM, [email protected] wrote: > 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:
This is the problem I thought about it. so I think that we will have to stay with copyFrom: > > > > > > Em 01/01/2011 17:48, Schwab,Wilhelm K < [email protected] > 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: [email protected] > [[email protected]] On Behalf Of Lukas Renggli > [[email protected]] > Sent: Saturday, January 01, 2011 2:06 PM > To: [email protected] > 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: [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 > > > >
