Should refactoring cope with symbols in Pharo or should we avoid symbols?

>
> On 30 sept. 2010, at 14:34, TimM wrote:
>
>> I logged issue http://code.google.com/p/pharo/issues/detail?id=2817 where I noted that code using a symbol like the following example doesn't get refactored in pharo (e.g. changing the modelChanged method doesn't change this code):
>>
>> model announcer subscribe: ElephantModelChanged send: #modelChanged to: self
>>
>> I was surprised by this as in Dolphin it works - and I never thought twice about it - to me, symbol = selector. Renaming a method, or adding a parameter to a method would also affect matching symbols.
>>
>> So I guess my wider question is, should I simply never use symbols in Pharo?
>
>
>
> We have plenty of use for symbols as selectors in Moose/Mondrian/Glamour, so yes I concur with the issue.
>
>
> --
> Simon
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> I logged issue http://code.google.com/p/pharo/issues/detail?id=2817 where I
> noted that code using a symbol like the following example doesn't get
> refactored in pharo (e.g. changing the modelChanged method doesn't change
> this code):
>
> model announcer subscribe: ElephantModelChanged send: #modelChanged to: self
>
> I was surprised by this as in Dolphin it works - and I never thought twice
> about it - to me, symbol = selector. Renaming a method, or adding a
> parameter to a method would also affect matching symbols.