Re: [Pharo-users] funny idea Symbol vs. Selector
Locked
Re: [Pharo-users] funny idea Symbol vs. Selector
 
|
On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <[hidden email]> wrote:
Maybe because there are things implemented in Symbol or similar that are responsabilities of a Selector? I have no idea. But I did a quick search and methods like flushCache, numArgs:,value:, isKeyword, cull:, etc, seems more from Selector Cheers mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [Pharo-users] funny idea Symbol vs. Selector
|
|
2010/8/24 Mariano Martinez Peck <[hidden email]>
Personally I find it slightly annoying. Symbols are only used as selectors by convention, and the VM has placed no restriction on what objects can be used as selectors so that, e.g. when aggressively shrinking one can replace Symbols with SmallIntegers. Introducing a Selector class would obscure this possibility even more. However I find use of the term "symbol" where "selector" is meant even more annoying. I *hate* methodSymbol in MethodReference. It should be selector.
2¢ Eliot
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [Pharo-users] funny idea Symbol vs. Selector
|
|
2010/8/24 Eliot Miranda <[hidden email]>:
> > > 2010/8/24 Mariano Martinez Peck <[hidden email]> >> >> >> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <[hidden email]> wrote: >>> >>> On 23 August 2010 23:26, stephane ducasse <[hidden email]> >>> 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. >>> > >>> >>> Hmm.. i don't see obvious advantages. Do you? >>> Most symbols (90% of cases), used as selectors, so it is likely that >>> such refactoring will be nothing more, >>> but just renaming the class :) > > Personally I find it slightly annoying. Symbols are only used as selectors > by convention, and the VM has placed no restriction on what objects can be > used as selectors so that, e.g. when aggressively shrinking one can replace > Symbols with SmallIntegers. Introducing a Selector class would obscure this > possibility even more. However I find use of the term "symbol" where > "selector" is meant even more annoying. I *hate* methodSymbol in > MethodReference. It should be selector. > 2¢ You're right, any object could be used as a selector, placed into corresponding method dictionary, but in practice syntax and compiler implies, that only symbols could be used as selectors. Selector is just a _role_ , and really, VM doesn't puts too much restrictions on it (thanks to everyone's most liked deity). In contrast, a Symbol, is a class, and instances of it can play multiple roles, including being selector. > Eliot > >> >> Maybe because there are things implemented in Symbol or similar that are >> responsabilities of a Selector? >> >> I have no idea. But I did a quick search and methods like flushCache, >> numArgs:,value:, isKeyword, cull:, etc, seems more from Selector >> >> Cheers >> >> mariano >> >>> >>> > Stef >>> > >>> > >>> > _______________________________________________ >>> > Pharo-users mailing list >>> > [hidden email] >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I like the idea to have a class Selector with all the protocol for
selectors there, so any symbol doesn´t have to understand selectors messages. Maybe you don't see short term advanteges of doing that, but I think that it will give conceptual clarity. On Tue, Aug 24, 2010 at 4:27 PM, Igor Stasenko <[hidden email]> wrote: > 2010/8/24 Eliot Miranda <[hidden email]>: >> >> >> 2010/8/24 Mariano Martinez Peck <[hidden email]> >>> >>> >>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <[hidden email]> wrote: >>>> >>>> On 23 August 2010 23:26, stephane ducasse <[hidden email]> >>>> 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. >>>> > >>>> >>>> Hmm.. i don't see obvious advantages. Do you? >>>> Most symbols (90% of cases), used as selectors, so it is likely that >>>> such refactoring will be nothing more, >>>> but just renaming the class :) >> >> Personally I find it slightly annoying. Symbols are only used as selectors >> by convention, and the VM has placed no restriction on what objects can be >> used as selectors so that, e.g. when aggressively shrinking one can replace >> Symbols with SmallIntegers. Introducing a Selector class would obscure this >> possibility even more. However I find use of the term "symbol" where >> "selector" is meant even more annoying. I *hate* methodSymbol in >> MethodReference. It should be selector. >> 2¢ > > You're right, any object could be used as a selector, placed into > corresponding method dictionary, > but in practice syntax and compiler implies, that only symbols could > be used as selectors. > > Selector is just a _role_ , and really, VM doesn't puts too much > restrictions on it (thanks to everyone's most liked deity). > In contrast, a Symbol, is a class, and instances of it can play > multiple roles, including being selector. > >> Eliot >> >>> >>> Maybe because there are things implemented in Symbol or similar that are >>> responsabilities of a Selector? >>> >>> I have no idea. But I did a quick search and methods like flushCache, >>> numArgs:,value:, isKeyword, cull:, etc, seems more from Selector >>> >>> Cheers >>> >>> mariano >>> >>>> >>>> > Stef >>>> > >>>> > >>>> > _______________________________________________ >>>> > Pharo-users mailing list >>>> > [hidden email] >>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>> > >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-users mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [Pharo-users] funny idea Symbol vs. Selector
|
|
Following this logic, an object should perform: aSelector rather than aSymbol.
Thus we should then write (self perform: (#myMessage as: Selector)) in order to keep up with conceptual clarity. Unless of course we alter the # syntax and let it answer a Selector rather than a Symbol ;) Then, we could write (#mySymbol as: Symbol), or just remove class Symbol ;) Seriously ? Nicolas 2010/8/24 Gabriel Brunstein <[hidden email]>: > I like the idea to have a class Selector with all the protocol for > selectors there, so any symbol doesn´t have to understand selectors > messages. > Maybe you don't see short term advanteges of doing that, but I think > that it will give conceptual clarity. > > On Tue, Aug 24, 2010 at 4:27 PM, Igor Stasenko <[hidden email]> wrote: >> 2010/8/24 Eliot Miranda <[hidden email]>: >>> >>> >>> 2010/8/24 Mariano Martinez Peck <[hidden email]> >>>> >>>> >>>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <[hidden email]> wrote: >>>>> >>>>> On 23 August 2010 23:26, stephane ducasse <[hidden email]> >>>>> 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. >>>>> > >>>>> >>>>> Hmm.. i don't see obvious advantages. Do you? >>>>> Most symbols (90% of cases), used as selectors, so it is likely that >>>>> such refactoring will be nothing more, >>>>> but just renaming the class :) >>> >>> Personally I find it slightly annoying. Symbols are only used as selectors >>> by convention, and the VM has placed no restriction on what objects can be >>> used as selectors so that, e.g. when aggressively shrinking one can replace >>> Symbols with SmallIntegers. Introducing a Selector class would obscure this >>> possibility even more. However I find use of the term "symbol" where >>> "selector" is meant even more annoying. I *hate* methodSymbol in >>> MethodReference. It should be selector. >>> 2¢ >> >> You're right, any object could be used as a selector, placed into >> corresponding method dictionary, >> but in practice syntax and compiler implies, that only symbols could >> be used as selectors. >> >> Selector is just a _role_ , and really, VM doesn't puts too much >> restrictions on it (thanks to everyone's most liked deity). >> In contrast, a Symbol, is a class, and instances of it can play >> multiple roles, including being selector. >> >>> Eliot >>> >>>> >>>> Maybe because there are things implemented in Symbol or similar that are >>>> responsabilities of a Selector? >>>> >>>> I have no idea. But I did a quick search and methods like flushCache, >>>> numArgs:,value:, isKeyword, cull:, etc, seems more from Selector >>>> >>>> Cheers >>>> >>>> mariano >>>> >>>>> >>>>> > Stef >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > Pharo-users mailing list >>>>> > [hidden email] >>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-users mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Or something like:
self perform: #myMessage asSelector. It would be just one message in Symbol and not all the selector related protocol you can also leave the current behavior for that message if your prefer, in my opinion is not so bad... On Tue, Aug 24, 2010 at 5:27 PM, Nicolas Cellier <[hidden email]> wrote: > Following this logic, an object should perform: aSelector rather than aSymbol. > Thus we should then write (self perform: (#myMessage as: Selector)) in > order to keep up with conceptual clarity. > Unless of course we alter the # syntax and let it answer a Selector > rather than a Symbol ;) > Then, we could write (#mySymbol as: Symbol), or just remove class Symbol ;) > > Seriously ? > > Nicolas > > 2010/8/24 Gabriel Brunstein <[hidden email]>: >> I like the idea to have a class Selector with all the protocol for >> selectors there, so any symbol doesn´t have to understand selectors >> messages. >> Maybe you don't see short term advanteges of doing that, but I think >> that it will give conceptual clarity. >> >> On Tue, Aug 24, 2010 at 4:27 PM, Igor Stasenko <[hidden email]> wrote: >>> 2010/8/24 Eliot Miranda <[hidden email]>: >>>> >>>> >>>> 2010/8/24 Mariano Martinez Peck <[hidden email]> >>>>> >>>>> >>>>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <[hidden email]> wrote: >>>>>> >>>>>> On 23 August 2010 23:26, stephane ducasse <[hidden email]> >>>>>> 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. >>>>>> > >>>>>> >>>>>> Hmm.. i don't see obvious advantages. Do you? >>>>>> Most symbols (90% of cases), used as selectors, so it is likely that >>>>>> such refactoring will be nothing more, >>>>>> but just renaming the class :) >>>> >>>> Personally I find it slightly annoying. Symbols are only used as selectors >>>> by convention, and the VM has placed no restriction on what objects can be >>>> used as selectors so that, e.g. when aggressively shrinking one can replace >>>> Symbols with SmallIntegers. Introducing a Selector class would obscure this >>>> possibility even more. However I find use of the term "symbol" where >>>> "selector" is meant even more annoying. I *hate* methodSymbol in >>>> MethodReference. It should be selector. >>>> 2¢ >>> >>> You're right, any object could be used as a selector, placed into >>> corresponding method dictionary, >>> but in practice syntax and compiler implies, that only symbols could >>> be used as selectors. >>> >>> Selector is just a _role_ , and really, VM doesn't puts too much >>> restrictions on it (thanks to everyone's most liked deity). >>> In contrast, a Symbol, is a class, and instances of it can play >>> multiple roles, including being selector. >>> >>>> Eliot >>>> >>>>> >>>>> Maybe because there are things implemented in Symbol or similar that are >>>>> responsabilities of a Selector? >>>>> >>>>> I have no idea. But I did a quick search and methods like flushCache, >>>>> numArgs:,value:, isKeyword, cull:, etc, seems more from Selector >>>>> >>>>> Cheers >>>>> >>>>> mariano >>>>> >>>>>> >>>>>> > Stef >>>>>> > >>>>>> > >>>>>> > _______________________________________________ >>>>>> > Pharo-users mailing list >>>>>> > [hidden email] >>>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-users mailing list >>>>>> [hidden email] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [Pharo-users] funny idea Symbol vs. Selector
|
|
In reply to this post by Eliot Miranda-2
>
> Hmm.. i don't see obvious advantages. Do you? > Most symbols (90% of cases), used as selectors, so it is likely that > such refactoring will be nothing more, > but just renaming the class :) > > Personally I find it slightly annoying. Symbols are only used as selectors by convention, and the VM has placed no restriction on what objects can be used as selectors so that, e.g. when aggressively shrinking one can replace Symbols with SmallIntegers. Introducing a Selector class would obscure this possibility even more. Ok. I was thinking the inverse. But again I was gazing at my screen and this idea cross it so I did not think more than that. > However I find use of the term "symbol" where "selector" is meant even more annoying. I *hate* methodSymbol in MethodReference. It should be selector. Me too :) Actually I wanted to play with the following idea if I find a fun student. We say ok we have packages/modules and we have a sealing mechanism and inside a seal package, ugly things can happen like aggressive inlining and one idea was also removing symbol method selectors. I'm curious what we could get. > > 2¢ > Eliot > > > Maybe because there are things implemented in Symbol or similar that are responsabilities of a Selector? > > I have no idea. But I did a quick search and methods like flushCache, numArgs:,value:, isKeyword, cull:, etc, seems more from Selector > > Cheers > > mariano > > > > Stef > > > > > > _______________________________________________ > > Pharo-users mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-users mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [Pharo-users] funny idea Symbol vs. Selector
|
|
In reply to this post by Gaboto
On 25 August 2010 00:14, Gabriel Brunstein <[hidden email]> wrote:
> Or something like: > self perform: #myMessage asSelector. > It would be just one message in Symbol and not all the selector related protocol > Yeah, and then code things like: 'foo' asSymbol asSelector great idea (pun intended)! > you can also leave the current behavior for that message if your > prefer, in my opinion is not so bad... > > > On Tue, Aug 24, 2010 at 5:27 PM, Nicolas Cellier > <[hidden email]> wrote: >> Following this logic, an object should perform: aSelector rather than aSymbol. >> Thus we should then write (self perform: (#myMessage as: Selector)) in >> order to keep up with conceptual clarity. >> Unless of course we alter the # syntax and let it answer a Selector >> rather than a Symbol ;) >> Then, we could write (#mySymbol as: Symbol), or just remove class Symbol ;) >> >> Seriously ? >> >> Nicolas >> >> 2010/8/24 Gabriel Brunstein <[hidden email]>: >>> I like the idea to have a class Selector with all the protocol for >>> selectors there, so any symbol doesn´t have to understand selectors >>> messages. >>> Maybe you don't see short term advanteges of doing that, but I think >>> that it will give conceptual clarity. >>> >>> On Tue, Aug 24, 2010 at 4:27 PM, Igor Stasenko <[hidden email]> wrote: >>>> 2010/8/24 Eliot Miranda <[hidden email]>: >>>>> >>>>> >>>>> 2010/8/24 Mariano Martinez Peck <[hidden email]> >>>>>> >>>>>> >>>>>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <[hidden email]> wrote: >>>>>>> >>>>>>> On 23 August 2010 23:26, stephane ducasse <[hidden email]> >>>>>>> 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. >>>>>>> > >>>>>>> >>>>>>> Hmm.. i don't see obvious advantages. Do you? >>>>>>> Most symbols (90% of cases), used as selectors, so it is likely that >>>>>>> such refactoring will be nothing more, >>>>>>> but just renaming the class :) >>>>> >>>>> Personally I find it slightly annoying. Symbols are only used as selectors >>>>> by convention, and the VM has placed no restriction on what objects can be >>>>> used as selectors so that, e.g. when aggressively shrinking one can replace >>>>> Symbols with SmallIntegers. Introducing a Selector class would obscure this >>>>> possibility even more. However I find use of the term "symbol" where >>>>> "selector" is meant even more annoying. I *hate* methodSymbol in >>>>> MethodReference. It should be selector. >>>>> 2¢ >>>> >>>> You're right, any object could be used as a selector, placed into >>>> corresponding method dictionary, >>>> but in practice syntax and compiler implies, that only symbols could >>>> be used as selectors. >>>> >>>> Selector is just a _role_ , and really, VM doesn't puts too much >>>> restrictions on it (thanks to everyone's most liked deity). >>>> In contrast, a Symbol, is a class, and instances of it can play >>>> multiple roles, including being selector. >>>> >>>>> Eliot >>>>> >>>>>> >>>>>> Maybe because there are things implemented in Symbol or similar that are >>>>>> responsabilities of a Selector? >>>>>> >>>>>> I have no idea. But I did a quick search and methods like flushCache, >>>>>> numArgs:,value:, isKeyword, cull:, etc, seems more from Selector >>>>>> >>>>>> Cheers >>>>>> >>>>>> mariano >>>>>> >>>>>>> >>>>>>> > Stef >>>>>>> > >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > Pharo-users mailing list >>>>>>> > [hidden email] >>>>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>>> > >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Stasenko AKA sig. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-users mailing list >>>>>>> [hidden email] >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> [hidden email] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [Pharo-users] funny idea Symbol vs. Selector
|
|
In reply to this post by Stéphane Ducasse
On 25 August 2010 00:23, Stéphane Ducasse <[hidden email]> wrote:
>> >> Hmm.. i don't see obvious advantages. Do you? >> Most symbols (90% of cases), used as selectors, so it is likely that >> such refactoring will be nothing more, >> but just renaming the class :) >> >> Personally I find it slightly annoying. Symbols are only used as selectors by convention, and the VM has placed no restriction on what objects can be used as selectors so that, e.g. when aggressively shrinking one can replace Symbols with SmallIntegers. Introducing a Selector class would obscure this possibility even more. > Ok. I was thinking the inverse. But again I was gazing at my screen and this idea cross it so I did not think more than that. > >> However I find use of the term "symbol" where "selector" is meant even more annoying. I *hate* methodSymbol in MethodReference. It should be selector. > > > Me too :) > Actually I wanted to play with the following idea if I find a fun student. > We say ok we have packages/modules and we have a sealing mechanism and inside a seal package, ugly things can happen like aggressive inlining and one idea was also removing symbol method selectors. I'm curious what we could get. > I think this is a wrong route. I dont see how selectors/symbols is related to any kind of sealing mechanism. Selectors should be globally unique, otherwise things like #perform: will not function properly, as well as any inter-package communications, since multiple packages could use same selector(s). >> >> 2¢ >> Eliot >> >> >> Maybe because there are things implemented in Symbol or similar that are responsabilities of a Selector? >> >> I have no idea. But I did a quick search and methods like flushCache, numArgs:,value:, isKeyword, cull:, etc, seems more from Selector >> >> Cheers >> >> mariano >> >> >> > Stef >> > >> > >> > _______________________________________________ >> > Pharo-users mailing list >> > [hidden email] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-users mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Igor Stasenko
??
i don´t see your point, what is wrong with doing: 'foo' asSymbol asSelector On Tue, Aug 24, 2010 at 6:43 PM, Igor Stasenko <[hidden email]> wrote: > On 25 August 2010 00:14, Gabriel Brunstein <[hidden email]> wrote: >> Or something like: >> self perform: #myMessage asSelector. >> It would be just one message in Symbol and not all the selector related protocol >> > > Yeah, and then code things like: > > 'foo' asSymbol asSelector > > great idea (pun intended)! > >> you can also leave the current behavior for that message if your >> prefer, in my opinion is not so bad... >> >> >> On Tue, Aug 24, 2010 at 5:27 PM, Nicolas Cellier >> <[hidden email]> wrote: >>> Following this logic, an object should perform: aSelector rather than aSymbol. >>> Thus we should then write (self perform: (#myMessage as: Selector)) in >>> order to keep up with conceptual clarity. >>> Unless of course we alter the # syntax and let it answer a Selector >>> rather than a Symbol ;) >>> Then, we could write (#mySymbol as: Symbol), or just remove class Symbol ;) >>> >>> Seriously ? >>> >>> Nicolas >>> >>> 2010/8/24 Gabriel Brunstein <[hidden email]>: >>>> I like the idea to have a class Selector with all the protocol for >>>> selectors there, so any symbol doesn´t have to understand selectors >>>> messages. >>>> Maybe you don't see short term advanteges of doing that, but I think >>>> that it will give conceptual clarity. >>>> >>>> On Tue, Aug 24, 2010 at 4:27 PM, Igor Stasenko <[hidden email]> wrote: >>>>> 2010/8/24 Eliot Miranda <[hidden email]>: >>>>>> >>>>>> >>>>>> 2010/8/24 Mariano Martinez Peck <[hidden email]> >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <[hidden email]> wrote: >>>>>>>> >>>>>>>> On 23 August 2010 23:26, stephane ducasse <[hidden email]> >>>>>>>> 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. >>>>>>>> > >>>>>>>> >>>>>>>> Hmm.. i don't see obvious advantages. Do you? >>>>>>>> Most symbols (90% of cases), used as selectors, so it is likely that >>>>>>>> such refactoring will be nothing more, >>>>>>>> but just renaming the class :) >>>>>> >>>>>> Personally I find it slightly annoying. Symbols are only used as selectors >>>>>> by convention, and the VM has placed no restriction on what objects can be >>>>>> used as selectors so that, e.g. when aggressively shrinking one can replace >>>>>> Symbols with SmallIntegers. Introducing a Selector class would obscure this >>>>>> possibility even more. However I find use of the term "symbol" where >>>>>> "selector" is meant even more annoying. I *hate* methodSymbol in >>>>>> MethodReference. It should be selector. >>>>>> 2¢ >>>>> >>>>> You're right, any object could be used as a selector, placed into >>>>> corresponding method dictionary, >>>>> but in practice syntax and compiler implies, that only symbols could >>>>> be used as selectors. >>>>> >>>>> Selector is just a _role_ , and really, VM doesn't puts too much >>>>> restrictions on it (thanks to everyone's most liked deity). >>>>> In contrast, a Symbol, is a class, and instances of it can play >>>>> multiple roles, including being selector. >>>>> >>>>>> Eliot >>>>>> >>>>>>> >>>>>>> Maybe because there are things implemented in Symbol or similar that are >>>>>>> responsabilities of a Selector? >>>>>>> >>>>>>> I have no idea. But I did a quick search and methods like flushCache, >>>>>>> numArgs:,value:, isKeyword, cull:, etc, seems more from Selector >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> mariano >>>>>>> >>>>>>>> >>>>>>>> > Stef >>>>>>>> > >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > Pharo-users mailing list >>>>>>>> > [hidden email] >>>>>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Igor Stasenko AKA sig. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-users mailing list >>>>>>>> [hidden email] >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> [hidden email] >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> [hidden email] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [Pharo-users] funny idea Symbol vs. Selector
|
|
On 25 August 2010 00:54, Gabriel Brunstein <[hidden email]> wrote:
> ?? > i don´t see your point, what is wrong with doing: > 'foo' asSymbol asSelector > as to me its awfully wrong. Why i do need to type two messages, where i could send just one? But its not important. I really wanna see the benefits of such distinction (no pun intended). > > On Tue, Aug 24, 2010 at 6:43 PM, Igor Stasenko <[hidden email]> wrote: >> On 25 August 2010 00:14, Gabriel Brunstein <[hidden email]> wrote: >>> Or something like: >>> self perform: #myMessage asSelector. >>> It would be just one message in Symbol and not all the selector related protocol >>> >> >> Yeah, and then code things like: >> >> 'foo' asSymbol asSelector >> >> great idea (pun intended)! >> >>> you can also leave the current behavior for that message if your >>> prefer, in my opinion is not so bad... >>> >>> >>> On Tue, Aug 24, 2010 at 5:27 PM, Nicolas Cellier >>> <[hidden email]> wrote: >>>> Following this logic, an object should perform: aSelector rather than aSymbol. >>>> Thus we should then write (self perform: (#myMessage as: Selector)) in >>>> order to keep up with conceptual clarity. >>>> Unless of course we alter the # syntax and let it answer a Selector >>>> rather than a Symbol ;) >>>> Then, we could write (#mySymbol as: Symbol), or just remove class Symbol ;) >>>> >>>> Seriously ? >>>> >>>> Nicolas >>>> >>>> 2010/8/24 Gabriel Brunstein <[hidden email]>: >>>>> I like the idea to have a class Selector with all the protocol for >>>>> selectors there, so any symbol doesn´t have to understand selectors >>>>> messages. >>>>> Maybe you don't see short term advanteges of doing that, but I think >>>>> that it will give conceptual clarity. >>>>> >>>>> On Tue, Aug 24, 2010 at 4:27 PM, Igor Stasenko <[hidden email]> wrote: >>>>>> 2010/8/24 Eliot Miranda <[hidden email]>: >>>>>>> >>>>>>> >>>>>>> 2010/8/24 Mariano Martinez Peck <[hidden email]> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <[hidden email]> wrote: >>>>>>>>> >>>>>>>>> On 23 August 2010 23:26, stephane ducasse <[hidden email]> >>>>>>>>> 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. >>>>>>>>> > >>>>>>>>> >>>>>>>>> Hmm.. i don't see obvious advantages. Do you? >>>>>>>>> Most symbols (90% of cases), used as selectors, so it is likely that >>>>>>>>> such refactoring will be nothing more, >>>>>>>>> but just renaming the class :) >>>>>>> >>>>>>> Personally I find it slightly annoying. Symbols are only used as selectors >>>>>>> by convention, and the VM has placed no restriction on what objects can be >>>>>>> used as selectors so that, e.g. when aggressively shrinking one can replace >>>>>>> Symbols with SmallIntegers. Introducing a Selector class would obscure this >>>>>>> possibility even more. However I find use of the term "symbol" where >>>>>>> "selector" is meant even more annoying. I *hate* methodSymbol in >>>>>>> MethodReference. It should be selector. >>>>>>> 2¢ >>>>>> >>>>>> You're right, any object could be used as a selector, placed into >>>>>> corresponding method dictionary, >>>>>> but in practice syntax and compiler implies, that only symbols could >>>>>> be used as selectors. >>>>>> >>>>>> Selector is just a _role_ , and really, VM doesn't puts too much >>>>>> restrictions on it (thanks to everyone's most liked deity). >>>>>> In contrast, a Symbol, is a class, and instances of it can play >>>>>> multiple roles, including being selector. >>>>>> >>>>>>> Eliot >>>>>>> >>>>>>>> >>>>>>>> Maybe because there are things implemented in Symbol or similar that are >>>>>>>> responsabilities of a Selector? >>>>>>>> >>>>>>>> I have no idea. But I did a quick search and methods like flushCache, >>>>>>>> numArgs:,value:, isKeyword, cull:, etc, seems more from Selector >>>>>>>> >>>>>>>> Cheers >>>>>>>> >>>>>>>> mariano >>>>>>>> >>>>>>>>> >>>>>>>>> > Stef >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > _______________________________________________ >>>>>>>>> > Pharo-users mailing list >>>>>>>>> > [hidden email] >>>>>>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Best regards, >>>>>>>>> Igor Stasenko AKA sig. >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Pharo-users mailing list >>>>>>>>> [hidden email] >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> [hidden email] >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> [hidden email] >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> [hidden email] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [Pharo-users] funny idea Symbol vs. Selector
|
|
On Tue, Aug 24, 2010 at 5:12 PM, Igor Stasenko <[hidden email]> wrote:
+1. Classes answer questions (how should I solve this problem?) and like scientific questions one should apply Occam's razor. Or as Einstein put it "as simple as possible but no simpler". So the Selector and associated protocol is just pointless complication.
But its not important. Yes it is. Go this route and you end up with bloat incomprehensibility and decline. KISS. I really wanna see the benefits of such distinction (no pun intended). quite. best Eliot
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [Pharo-users] funny idea Symbol vs. Selector
|
|
2010/8/25 Eliot Miranda <[hidden email]>:
> > > On Tue, Aug 24, 2010 at 5:12 PM, Igor Stasenko <[hidden email]> wrote: >> >> On 25 August 2010 00:54, Gabriel Brunstein <[hidden email]> wrote: >> > ?? >> > i don´t see your point, what is wrong with doing: >> > 'foo' asSymbol asSelector >> > >> as to me its awfully wrong. Why i do need to type two messages, where >> i could send just one? > > +1. > Classes answer questions (how should I solve this problem?) and like > scientific questions one should apply Occam's razor. Or as Einstein put it > "as simple as possible but no simpler". So the Selector and associated > protocol is just pointless complication. > >> >> But its not important. > > Yes it is. Go this route and you end up with bloat incomprehensibility and > decline. KISS. > dict at: 'foo' asDictionaryKey ;) >> >> I really wanna see the benefits of such distinction (no pun intended). > > quite. > best > Eliot > >> >> > >> > On Tue, Aug 24, 2010 at 6:43 PM, Igor Stasenko <[hidden email]> >> > wrote: >> >> On 25 August 2010 00:14, Gabriel Brunstein <[hidden email]> wrote: >> >>> Or something like: >> >>> self perform: #myMessage asSelector. >> >>> It would be just one message in Symbol and not all the selector >> >>> related protocol >> >>> >> >> >> >> Yeah, and then code things like: >> >> >> >> 'foo' asSymbol asSelector >> >> >> >> great idea (pun intended)! >> >> >> >>> you can also leave the current behavior for that message if your >> >>> prefer, in my opinion is not so bad... >> >>> >> >>> >> >>> On Tue, Aug 24, 2010 at 5:27 PM, Nicolas Cellier >> >>> <[hidden email]> wrote: >> >>>> Following this logic, an object should perform: aSelector rather than >> >>>> aSymbol. >> >>>> Thus we should then write (self perform: (#myMessage as: Selector)) >> >>>> in >> >>>> order to keep up with conceptual clarity. >> >>>> Unless of course we alter the # syntax and let it answer a Selector >> >>>> rather than a Symbol ;) >> >>>> Then, we could write (#mySymbol as: Symbol), or just remove class >> >>>> Symbol ;) >> >>>> >> >>>> Seriously ? >> >>>> >> >>>> Nicolas >> >>>> >> >>>> 2010/8/24 Gabriel Brunstein <[hidden email]>: >> >>>>> I like the idea to have a class Selector with all the protocol for >> >>>>> selectors there, so any symbol doesn´t have to understand selectors >> >>>>> messages. >> >>>>> Maybe you don't see short term advanteges of doing that, but I think >> >>>>> that it will give conceptual clarity. >> >>>>> >> >>>>> On Tue, Aug 24, 2010 at 4:27 PM, Igor Stasenko <[hidden email]> >> >>>>> wrote: >> >>>>>> 2010/8/24 Eliot Miranda <[hidden email]>: >> >>>>>>> >> >>>>>>> >> >>>>>>> 2010/8/24 Mariano Martinez Peck <[hidden email]> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko >> >>>>>>>> <[hidden email]> wrote: >> >>>>>>>>> >> >>>>>>>>> On 23 August 2010 23:26, stephane ducasse >> >>>>>>>>> <[hidden email]> >> >>>>>>>>> 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. >> >>>>>>>>> > >> >>>>>>>>> >> >>>>>>>>> Hmm.. i don't see obvious advantages. Do you? >> >>>>>>>>> Most symbols (90% of cases), used as selectors, so it is likely >> >>>>>>>>> that >> >>>>>>>>> such refactoring will be nothing more, >> >>>>>>>>> but just renaming the class :) >> >>>>>>> >> >>>>>>> Personally I find it slightly annoying. Symbols are only used as >> >>>>>>> selectors >> >>>>>>> by convention, and the VM has placed no restriction on what >> >>>>>>> objects can be >> >>>>>>> used as selectors so that, e.g. when aggressively shrinking one >> >>>>>>> can replace >> >>>>>>> Symbols with SmallIntegers. Introducing a Selector class would >> >>>>>>> obscure this >> >>>>>>> possibility even more. However I find use of the term "symbol" >> >>>>>>> where >> >>>>>>> "selector" is meant even more annoying. I *hate* methodSymbol in >> >>>>>>> MethodReference. It should be selector. >> >>>>>>> 2¢ >> >>>>>> >> >>>>>> You're right, any object could be used as a selector, placed into >> >>>>>> corresponding method dictionary, >> >>>>>> but in practice syntax and compiler implies, that only symbols >> >>>>>> could >> >>>>>> be used as selectors. >> >>>>>> >> >>>>>> Selector is just a _role_ , and really, VM doesn't puts too much >> >>>>>> restrictions on it (thanks to everyone's most liked deity). >> >>>>>> In contrast, a Symbol, is a class, and instances of it can play >> >>>>>> multiple roles, including being selector. >> >>>>>> >> >>>>>>> Eliot >> >>>>>>> >> >>>>>>>> >> >>>>>>>> Maybe because there are things implemented in Symbol or similar >> >>>>>>>> that are >> >>>>>>>> responsabilities of a Selector? >> >>>>>>>> >> >>>>>>>> I have no idea. But I did a quick search and methods like >> >>>>>>>> flushCache, >> >>>>>>>> numArgs:,value:, isKeyword, cull:, etc, seems more from Selector >> >>>>>>>> >> >>>>>>>> Cheers >> >>>>>>>> >> >>>>>>>> mariano >> >>>>>>>> >> >>>>>>>>> >> >>>>>>>>> > Stef >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > _______________________________________________ >> >>>>>>>>> > Pharo-users mailing list >> >>>>>>>>> > [hidden email] >> >>>>>>>>> > >> >>>>>>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >>>>>>>>> > >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> -- >> >>>>>>>>> Best regards, >> >>>>>>>>> Igor Stasenko AKA sig. >> >>>>>>>>> >> >>>>>>>>> _______________________________________________ >> >>>>>>>>> Pharo-users mailing list >> >>>>>>>>> [hidden email] >> >>>>>>>>> >> >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> _______________________________________________ >> >>>>>>>> Pharo-project mailing list >> >>>>>>>> [hidden email] >> >>>>>>>> >> >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >>>>>>> >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> Pharo-project mailing list >> >>>>>>> [hidden email] >> >>>>>>> >> >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Best regards, >> >>>>>> Igor Stasenko AKA sig. >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Pharo-project mailing list >> >>>>>> [hidden email] >> >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Pharo-project mailing list >> >>>>> [hidden email] >> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >>>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Pharo-project mailing list >> >>>> [hidden email] >> >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >>>> >> >>> >> >>> _______________________________________________ >> >>> Pharo-project mailing list >> >>> [hidden email] >> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >>> >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko AKA sig. >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> [hidden email] >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > [hidden email] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [Pharo-users] funny idea Symbol vs. Selector
|
|
In reply to this post by Igor Stasenko
lol
:) I was more thinking that selector could be a subclass of symbol to avoid such problem On Aug 24, 2010, at 11:43 PM, Igor Stasenko wrote: > On 25 August 2010 00:14, Gabriel Brunstein <[hidden email]> wrote: >> Or something like: >> self perform: #myMessage asSelector. >> It would be just one message in Symbol and not all the selector related protocol >> > > Yeah, and then code things like: > > 'foo' asSymbol asSelector > > great idea (pun intended)! > >> you can also leave the current behavior for that message if your >> prefer, in my opinion is not so bad... >> >> >> On Tue, Aug 24, 2010 at 5:27 PM, Nicolas Cellier >> <[hidden email]> wrote: >>> Following this logic, an object should perform: aSelector rather than aSymbol. >>> Thus we should then write (self perform: (#myMessage as: Selector)) in >>> order to keep up with conceptual clarity. >>> Unless of course we alter the # syntax and let it answer a Selector >>> rather than a Symbol ;) >>> Then, we could write (#mySymbol as: Symbol), or just remove class Symbol ;) >>> >>> Seriously ? >>> >>> Nicolas >>> >>> 2010/8/24 Gabriel Brunstein <[hidden email]>: >>>> I like the idea to have a class Selector with all the protocol for >>>> selectors there, so any symbol doesn´t have to understand selectors >>>> messages. >>>> Maybe you don't see short term advanteges of doing that, but I think >>>> that it will give conceptual clarity. >>>> >>>> On Tue, Aug 24, 2010 at 4:27 PM, Igor Stasenko <[hidden email]> wrote: >>>>> 2010/8/24 Eliot Miranda <[hidden email]>: >>>>>> >>>>>> >>>>>> 2010/8/24 Mariano Martinez Peck <[hidden email]> >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <[hidden email]> wrote: >>>>>>>> >>>>>>>> On 23 August 2010 23:26, stephane ducasse <[hidden email]> >>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>>> Hmm.. i don't see obvious advantages. Do you? >>>>>>>> Most symbols (90% of cases), used as selectors, so it is likely that >>>>>>>> such refactoring will be nothing more, >>>>>>>> but just renaming the class :) >>>>>> >>>>>> Personally I find it slightly annoying. Symbols are only used as selectors >>>>>> by convention, and the VM has placed no restriction on what objects can be >>>>>> used as selectors so that, e.g. when aggressively shrinking one can replace >>>>>> Symbols with SmallIntegers. Introducing a Selector class would obscure this >>>>>> possibility even more. However I find use of the term "symbol" where >>>>>> "selector" is meant even more annoying. I *hate* methodSymbol in >>>>>> MethodReference. It should be selector. >>>>>> 2¢ >>>>> >>>>> You're right, any object could be used as a selector, placed into >>>>> corresponding method dictionary, >>>>> but in practice syntax and compiler implies, that only symbols could >>>>> be used as selectors. >>>>> >>>>> Selector is just a _role_ , and really, VM doesn't puts too much >>>>> restrictions on it (thanks to everyone's most liked deity). >>>>> In contrast, a Symbol, is a class, and instances of it can play >>>>> multiple roles, including being selector. >>>>> >>>>>> Eliot >>>>>> >>>>>>> >>>>>>> Maybe because there are things implemented in Symbol or similar that are >>>>>>> responsabilities of a Selector? >>>>>>> >>>>>>> I have no idea. But I did a quick search and methods like flushCache, >>>>>>> numArgs:,value:, isKeyword, cull:, etc, seems more from Selector >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> mariano >>>>>>> >>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Pharo-users mailing list >>>>>>>>> [hidden email] >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Igor Stasenko AKA sig. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-users mailing list >>>>>>>> [hidden email] >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> [hidden email] >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> [hidden email] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |