On 25 August 2010 22:33, Igor Stasenko <[email protected]> wrote: > On 25 August 2010 21:11, Hernan Wilkinson <[email protected]> > 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 >> <[email protected]> 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 <[email protected]>: >>> >> 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 >>> >>> [email protected] >>> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >> >>> >> >>> >> _______________________________________________ >>> >> Pharo-users mailing list >>> >> [email protected] >>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >> >>> > >>> > _______________________________________________ >>> > Pharo-users mailing list >>> > [email protected] >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> [email protected] >>> 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: [email protected] >> site: http://www.10Pines.com >> >> _______________________________________________ >> Pharo-users mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-users mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
