Re: 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 <[hidden email]>:
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:

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: