Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken (pharo@googlecode.com)
Nicolas wrote:
Then group the selectors (first, first: etc..), explain that they are extensions, and don't need a copy prefix, because anyway most messages will do a copy.
You are aware first doesn't copy, do you? The explanation should be that you always have to take a look at the implementation to see if it copies or not (or sometimes), and explain when it doesn't matter (small integers, characters). Stephan
2011/1/8 Stephan Eggermont <stephan@stack.nl>:
Nicolas wrote:
Then group the selectors (first, first: etc..), explain that they are extensions, and don't need a copy prefix, because anyway most messages will do a copy.
You are aware first doesn't copy, do you? The explanation should be that you always have to take a look at the implementation to see if it copies or not (or sometimes), and explain when it doesn't matter (small integers, characters).
Stephan
You mean something like: | collec | collec := #('foo' 'bar'). shallowCopy := collec copy. self assert: collec first == shallowCopy first Well, yes those copies are shallow, but what's the difference between copy, copyFrom:to: first, first: etc... with this respect ? Nicolas
On 08 Jan 2011, at 23:07, Nicolas Cellier wrote:
You mean something like:
| collec | collec := #('foo' 'bar'). shallowCopy := collec copy. self assert: collec first == shallowCopy first
Well, yes those copies are shallow, but what's the difference between copy, copyFrom:to: first, first: etc... with this respect ?
I think Stephan intended to say that the return result of #first is not a copy of (parts of) the receiver. #first is an accessor, not a copy message. And yes, the rule of thumb is that one reads the comments (or implementation) of a method to understand it, rather than (only) trying to guess it's semantics from its selector. We all got used to coding like that in Smalltalk. However, it's _just_ a rule of thumb that comments on top of the method body should document the method. Not all methods do it, and people coming from different languages and development environments are not immediately comfortable because they 'need to look at the implementation of an API to understand it'. So, I think there is something we can learn from other development environments: in XCode, for example, you can request the documentation of a method in a small 'hover window' by a <ctrl>+<click> on the method name. I wonder if such a system in Smalltalk development environment would make documenting a method more important, and thus, force people to write and use it more.... Johan
+ 1 does anybody want to implement this hovering excellent idea. On Jan 9, 2011, at 10:02 AM, Johan Brichau wrote:
And yes, the rule of thumb is that one reads the comments (or implementation) of a method to understand it, rather than (only) trying to guess it's semantics from its selector. We all got used to coding like that in Smalltalk. However, it's _just_ a rule of thumb that comments on top of the method body should document the method. Not all methods do it, and people coming from different languages and development environments are not immediately comfortable because they 'need to look at the implementation of an API to understand it'. So, I think there is something we can learn from other development environments: in XCode, for example, you can request the documentation of a method in a small 'hover window' by a <ctrl>+<click> on the method name. I wonder if such a system in Smalltalk development environment would make documenting a method more important, and thus, force people to write and use it more....
Andy agreed to pair program it with me, starting next week. Unless someone beats us to it ;-) On 09 Jan 2011, at 10:12, Stéphane Ducasse wrote:
+ 1
does anybody want to implement this hovering excellent idea.
On Jan 9, 2011, at 10:02 AM, Johan Brichau wrote:
And yes, the rule of thumb is that one reads the comments (or implementation) of a method to understand it, rather than (only) trying to guess it's semantics from its selector. We all got used to coding like that in Smalltalk. However, it's _just_ a rule of thumb that comments on top of the method body should document the method. Not all methods do it, and people coming from different languages and development environments are not immediately comfortable because they 'need to look at the implementation of an API to understand it'. So, I think there is something we can learn from other development environments: in XCode, for example, you can request the documentation of a method in a small 'hover window' by a <ctrl>+<click> on the method name. I wonder if such a system in Smalltalk development environment would make documenting a method more important, and thus, force people to write and use it more....
Excellent You know what I'm dreaming of (may be this is already in) you get the list of methods in the method list and you start to type and automatically all the methods not matching are greyed out or we only see the methods matching the beginning. Stef On Jan 9, 2011, at 10:26 AM, Johan Brichau wrote:
Andy agreed to pair program it with me, starting next week. Unless someone beats us to it ;-)
On 09 Jan 2011, at 10:12, Stéphane Ducasse wrote:
+ 1
does anybody want to implement this hovering excellent idea.
On Jan 9, 2011, at 10:02 AM, Johan Brichau wrote:
And yes, the rule of thumb is that one reads the comments (or implementation) of a method to understand it, rather than (only) trying to guess it's semantics from its selector. We all got used to coding like that in Smalltalk. However, it's _just_ a rule of thumb that comments on top of the method body should document the method. Not all methods do it, and people coming from different languages and development environments are not immediately comfortable because they 'need to look at the implementation of an API to understand it'. So, I think there is something we can learn from other development environments: in XCode, for example, you can request the documentation of a method in a small 'hover window' by a <ctrl>+<click> on the method name. I wonder if such a system in Smalltalk development environment would make documenting a method more important, and thus, force people to write and use it more....
participants (4)
-
Johan Brichau -
Nicolas Cellier -
Stephan Eggermont -
Stéphane Ducasse