[Pharo-project] An intuitive (or screwed) #copyFrom:
('if this isn''t broken' copyFrom: 15) ~= 'broken' ifTrue:['this is screwed'] ifFalse:['this is intuitive'] Evaluate that in any Pharo workspace and it will show you. Reported here. Status? invalid Came on guys. Really? 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?
On 1 January 2011 18:15, Sebastian Sastre <seb@sebastianconcept.com> wrote:
('if this isn''t broken' copyFrom: Â 15) ~= 'broken' ifTrue:['this is screwed'] ifFalse:['this is intuitive']
my first thought about it was that it should answer own copy , starting from 15th element :)
Evaluate that in any Pharo workspace and it will show you. Reported here. Status? invalid
but then i saw its implementation... ouch...
Came on guys. Really? 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?
hey. slow down.. 8 arguments is too much for it, but i can understand how deeply such thing could hurt :) This is really screwed primitive. -- Best regards, Igor Stasenko AKA sig.
Yes, this method name is unfortunate... I think we should just rename the method and tag copyFrom: as deprecated. And some versions later we'll implement copyFrom: as we think is appropriate. Cheers, Adrian BTW Sebastian, I think your energy would be better invested into producing a changeset and challenging the "invalid"-tag of Henrik in a rational way than to writing a "are you stupid?"-mail. On Jan 1, 2011, at 19:13 , Igor Stasenko wrote:
On 1 January 2011 18:15, Sebastian Sastre <seb@sebastianconcept.com> wrote:
('if this isn''t broken' copyFrom: 15) ~= 'broken' ifTrue:['this is screwed'] ifFalse:['this is intuitive']
my first thought about it was that it should answer own copy , starting from 15th element :)
Evaluate that in any Pharo workspace and it will show you. Reported here. Status? invalid
but then i saw its implementation... ouch...
Came on guys. Really? 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?
hey. slow down..
8 arguments is too much for it, but i can understand how deeply such thing could hurt :)
This is really screwed primitive.
-- Best regards, Igor Stasenko AKA sig.
right please open a bug entry and provide cs :) Stef
Yes, this method name is unfortunate...
I think we should just rename the method and tag copyFrom: as deprecated. And some versions later we'll implement copyFrom: as we think is appropriate.
Cheers, Adrian
BTW Sebastian, I think your energy would be better invested into producing a changeset and challenging the "invalid"-tag of Henrik in a rational way than to writing a "are you stupid?"-mail.
I like copyStateFrom: as a name lukas there is copyFrom:to: and copyFrom: make a lot of sense as copyFrom: index until the end. Stef
On 1 January 2011 20:59, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I like copyStateFrom: as a name
lukas     there is copyFrom:to:     and copyFrom: make a lot of sense as copyFrom: index until the end.
+1 in the presence of #copyFrom:to: the current implementation of #copyFrom: is misleading. We should pick another name to reflect a completely different behavior.
Stef
-- Best regards, Igor Stasenko AKA sig.
+1 ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, January 01, 2011 2:59 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] An intuitive (or screwed) #copyFrom: I like copyStateFrom: as a name lukas there is copyFrom:to: and copyFrom: make a lot of sense as copyFrom: index until the end. Stef
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
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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, January 01, 2011 1:29 PM To: Pharo-project@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
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 <bschwab@anest.ufl.edu> 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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, January 01, 2011 1:29 PM To: Pharo-project@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
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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli@gmail.com] Sent: Saturday, January 01, 2011 2:06 PM To: Pharo-project@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 <bschwab@anest.ufl.edu> 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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, January 01, 2011 1:29 PM To: Pharo-project@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
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@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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli@gmail.com] Sent: Saturday, January 01, 2011 2:06 PM To: Pharo-project@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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, January 01, 2011 1:29 PM To: Pharo-project@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
On Jan 2, 2011, at 1:33 AM, csrabak@bol.com.br 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 < bschwab@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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli@gmail.com] Sent: Saturday, January 01, 2011 2:06 PM To: Pharo-project@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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, January 01, 2011 1:29 PM To: Pharo-project@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
On 2 January 2011 10:37, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jan 2, 2011, at 1:33 AM, csrabak@bol.com.br 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:
For the future, I think that the functionality of #copyFrom:to: should be provided by #at: using an interval/collection as argument (something that is pretty common in about any modern programming language). For now #copyFrom:to: is part of ANSI and should not be touched. Lukas -- Lukas Renggli www.lukas-renggli.ch
Hehehe. While I was considering whether or not to chip in on this thread, two thoughts passed through my mind. The first was that this is one of those annoying silent failures that Wilhelm would surely pick up on (so I didn't need to bring it up). The second was that #copyFrom: really should be called #copyStateFrom: to more accurately reflect what it does, and should be used for. So now this reply is completely redundant, since Wilhelm also suggested the same thing, or maybe I should just stop here and write "+1" instead :-p -- Cheers, Peter On Sat, Jan 1, 2011 at 7:39 PM, Schwab,Wilhelm K <bschwab@anest.ufl.edu>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@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, January 01, 2011 1:29 PM To: Pharo-project@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
Peter, Feel free to beat me to pointing out silent failures; I'm glad I'm not alone in seeing them as something to be found and eliminated, and it never hurts for the truth to be heard from multiple directions. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Peter Hugosson-Miller [oldmanlink@gmail.com] Sent: Saturday, January 01, 2011 2:30 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] An intuitive (or screwed) #copyFrom: Hehehe. While I was considering whether or not to chip in on this thread, two thoughts passed through my mind. The first was that this is one of those annoying silent failures that Wilhelm would surely pick up on (so I didn't need to bring it up). The second was that #copyFrom: really should be called #copyStateFrom: to more accurately reflect what it does, and should be used for. So now this reply is completely redundant, since Wilhelm also suggested the same thing, or maybe I should just stop here and write "+1" instead :-p -- Cheers, Peter On Sat, Jan 1, 2011 at 7:39 PM, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> 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@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>] Sent: Saturday, January 01, 2011 1:29 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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
participants (8)
-
Adrian Lienhard -
csrabak＠bol.com.br -
Igor Stasenko -
Lukas Renggli -
Peter Hugosson-Miller -
Schwab,Wilhelm K -
Sebastian Sastre -
Stéphane Ducasse