> On 25 August 2010 21:11, Hernan Wilkinson <[hidden email]> wrote:
>> From the design point of view, I like the idea, a selector is not a symbol
>> and we can see that clearly in the Symbol protocol, like Mariano and Gabriel
>> said, implements messages that are related to selector behavior... Why
>> symbols respond to numArgs:, precedence, isUnary, etc? those are a selectors
>> responsibilities... not all symbols are selectors... so for me, it is a good
>> idea.
>
> not all symbols are selectors...
> but you never tell, that they could not be, once you load new package
> or write more code.
>
> I see the need of having a separate subclass for Symbol , instead of
> stopping at String,
> because it have to maintain uniqueness and immutability.
>
> String + uniqueness + immutability => Symbol
>
> so, there is a strong reason for having a separate class for it, but
>
> Symbol + ??? => Selector
>
> give me a strong reason.
>
> i like the idea of shrinking a Symbol's protocol and putting it into
> lean and clean place - Symbol.

> But this is not strong enough.
> In practice, such shrinking, could lead to explosion of complexity in
> many other places.
>
>
> 'foo' = #foo  ->true
> #foo = 'foo' -> true
>
> #foo asSelector = #foo ??
>
> if so, then
> #foo hash = #foo asSelector hash ?
>
> and , obviously
> #foo == #foo asSelector  => false
>
> which means, that mixing selectors and symbols in a single collection
> will be very bad idea,
> and source of bugs and confusion.
> But what gives us a uniqueness of symbols is, that we don't need to
> use #= for comparing them,
> but #== , which is much faster. Right?
>
> Now, if you introduce selectors, there is no uniqueness anymore, since
> selector is a symbol (since it is a subclass of it), and must honor
> the rules of its ancestor..
> but its not.
> The only way how to deal with that is to make particular symbol
> (sub)instance to be either
> an instance of Symbol or Selector but not both.
> This means that in system you could have either
> #foo
> or
> #foo asSelector
> but not both, otherwise you will violate the uniqueness rule.
>
> Objects could play many roles, depending on their use. Just take a
> look at Object protocol, and answer yourself, how
> many of these methods is userful in some specific case (such as an
> object used to identify a message - selector).
> So, if you want to dissect all roles onto a set of specific
> (sub)classes, i propose to start from an Object class,
> and then, gradually get to a Symbol.
>
>> This idea brings implementation challenges of course, but nothing new :-)
>> On Wed, Aug 25, 2010 at 2:05 PM, Stéphane Ducasse
>> <[hidden email]> wrote:
>>>
>>> :)
>>>
>>> Your previous mail was what the bee I had in my bonnet :)
>>>
>>> Stef
>>>
>>> On Aug 25, 2010, at 6:57 PM, Hernán Morales Durand wrote:
>>>
>>> > Actually I think is one of the better ideas I've read in this list.
>>> > Too bad nobody seems interested in semiotics :(
>>> >
>>> > 2010/8/25 Stéphane Ducasse <[hidden email]>:
>>> >> I;m sorry that I raised a stupid idea.
>>> >> Don;t bash people for me :)
>>> >>
>>> >> On Aug 23, 2010, at 10:26 PM, stephane ducasse wrote:
>>> >>
>>> >>> Hi guys
>>> >>>
>>> >>> I'm thinking aloud...
>>> >>> I was wondering if we could not take advantage of a new class:
>>> >>> Selector.
>>> >>> MethodDict would only contain selectors and not symbols.
>>> >>>
>>> >>> I remember that I talked about that with hernan.
>>> >>>
>>> >>> Stef
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> Pharo-users mailing list
>>> >>> [hidden email]
>>> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> Pharo-users mailing list
>>> >> [hidden email]
>>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>> >>
>>> >
>>> > _______________________________________________
>>> > Pharo-users mailing list
>>> > [hidden email]
>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>>
>>>
>>> _______________________________________________
>>> Pharo-users mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>>
>>
>> --
>> Hernán Wilkinson
>> Agile Software Development, Teaching & Coaching
>> Mobile: +54 - 11 - 4470 - 7207
>> email: [hidden email]
>> site: http://www.10Pines.com
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>