On 25 August 2010 22:33, Igor Stasenko <siguctua@gmail.com> wrote:
On 25 August 2010 21:11, Hernan Wilkinson <hernan.wilkinson@10pines.com> 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.
oops, clean place is obviously Selector here.
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 <stephane.ducasse@inria.fr> 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 <stephane.ducasse@inria.fr>:
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 Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr 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: hernan.wilkinson@10Pines.com site: http://www.10Pines.com
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.