- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Pharo-users] funny idea Symbol vs. Selector

by Igor Stasenko

2010/8/25 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Tue, Aug 24, 2010 at 5:12 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 25 August 2010 00:54, Gabriel Brunstein <gaboto(a)gmail.com> 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 <siguctua(a)gmail.com> >> > wrote: >> >> On 25 August 2010 00:14, Gabriel Brunstein <gaboto(a)gmail.com> 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 >> >>> <nicolas.cellier.aka.nice(a)gmail.com> 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 <gaboto(a)gmail.com>: >> >>>>> 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 <siguctua(a)gmail.com> >> >>>>> wrote: >> >>>>>> 2010/8/24 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>>>>>> >> >>>>>>> >> >>>>>>> 2010/8/24 Mariano Martinez Peck <marianopeck(a)gmail.com> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko >> >>>>>>>> <siguctua(a)gmail.com> wrote: >> >>>>>>>>> >> >>>>>>>>> On 23 August 2010 23:26, stephane ducasse >> >>>>>>>>> <stephane.ducasse(a)free.fr> >> >>>>>>>>> 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 >> >>>>>>>>> > Pharo-users(a)lists.gforge.inria.fr >> >>>>>>>>> > >> >>>>>>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >>>>>>>>> > >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> -- >> >>>>>>>>> Best regards, >> >>>>>>>>> Igor Stasenko AKA sig. >> >>>>>>>>> >> >>>>>>>>> _______________________________________________ >> >>>>>>>>> Pharo-users mailing list >> >>>>>>>>> Pharo-users(a)lists.gforge.inria.fr >> >>>>>>>>> >> >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> _______________________________________________ >> >>>>>>>> Pharo-project mailing list >> >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >> >>>>>>>> >> >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >>>>>>> >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> Pharo-project mailing list >> >>>>>>> Pharo-project(a)lists.gforge.inria.fr >> >>>>>>> >> >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Best regards, >> >>>>>> Igor Stasenko AKA sig. >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Pharo-project mailing list >> >>>>>> Pharo-project(a)lists.gforge.inria.fr >> >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Pharo-project mailing list >> >>>>> Pharo-project(a)lists.gforge.inria.fr >> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >>>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Pharo-project mailing list >> >>>> Pharo-project(a)lists.gforge.inria.fr >> >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >>>> >> >>> >> >>> _______________________________________________ >> >>> Pharo-project mailing list >> >>> Pharo-project(a)lists.gforge.inria.fr >> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >>> >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko AKA sig. >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Aug. 25, 2010

Re: [Pharo-project] [Pharo-users] funny idea Symbol vs. Selector

by Eliot Miranda

On Tue, Aug 24, 2010 at 5:12 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 August 2010 00:54, Gabriel Brunstein <gaboto(a)gmail.com> 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. > 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 <siguctua(a)gmail.com> > wrote: > >> On 25 August 2010 00:14, Gabriel Brunstein <gaboto(a)gmail.com> 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 > >>> <nicolas.cellier.aka.nice(a)gmail.com> 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 <gaboto(a)gmail.com>: > >>>>> 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 <siguctua(a)gmail.com> > wrote: > >>>>>> 2010/8/24 Eliot Miranda <eliot.miranda(a)gmail.com>: > >>>>>>> > >>>>>>> > >>>>>>> 2010/8/24 Mariano Martinez Peck <marianopeck(a)gmail.com> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko < > siguctua(a)gmail.com> wrote: > >>>>>>>>> > >>>>>>>>> On 23 August 2010 23:26, stephane ducasse < > stephane.ducasse(a)free.fr> > >>>>>>>>> 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 > >>>>>>>>> > Pharo-users(a)lists.gforge.inria.fr > >>>>>>>>> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >>>>>>>>> > > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Best regards, > >>>>>>>>> Igor Stasenko AKA sig. > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Pharo-users mailing list > >>>>>>>>> Pharo-users(a)lists.gforge.inria.fr > >>>>>>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Pharo-project mailing list > >>>>>>>> Pharo-project(a)lists.gforge.inria.fr > >>>>>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Pharo-project mailing list > >>>>>>> Pharo-project(a)lists.gforge.inria.fr > >>>>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Best regards, > >>>>>> Igor Stasenko AKA sig. > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Pharo-project mailing list > >>>>>> Pharo-project(a)lists.gforge.inria.fr > >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>>> > >>>>> _______________________________________________ > >>>>> Pharo-project mailing list > >>>>> Pharo-project(a)lists.gforge.inria.fr > >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Pharo-project mailing list > >>>> Pharo-project(a)lists.gforge.inria.fr > >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>> > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko AKA sig. > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 25, 2010

Re: [Pharo-project] [Pharo-users] funny idea Symbol vs. Selector

by Igor Stasenko

On 25 August 2010 00:54, Gabriel Brunstein <gaboto(a)gmail.com> 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 <siguctua(a)gmail.com> wrote: >> On 25 August 2010 00:14, Gabriel Brunstein <gaboto(a)gmail.com> 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 >>> <nicolas.cellier.aka.nice(a)gmail.com> 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 <gaboto(a)gmail.com>: >>>>> 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 <siguctua(a)gmail.com> wrote: >>>>>> 2010/8/24 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>>>>> >>>>>>> >>>>>>> 2010/8/24 Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>> On 23 August 2010 23:26, stephane ducasse <stephane.ducasse(a)free.fr> >>>>>>>>> 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 >>>>>>>>> > Pharo-users(a)lists.gforge.inria.fr >>>>>>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Best regards, >>>>>>>>> Igor Stasenko AKA sig. >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Pharo-users mailing list >>>>>>>>> Pharo-users(a)lists.gforge.inria.fr >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Aug. 25, 2010

Re: [Pharo-project] cog vm

by Levente Uzonyi

On Tue, 24 Aug 2010, Sven Van Caekenberghe wrote: > > On 24 Aug 2010, at 11:42, Levente Uzonyi wrote: > >> These apps use Squeak trunk images (updated regularly, but manually) with Seaside 3.0 (some with Comet), WebClient, SqueakSSL, OSProcess, PostgresV3. > > Is PostgresV3 production ready, last time I checked it seemed like it was not ready vs the older PostgresV2. I must have missed its progress (no pun intended). We're using it in production for a year now (instead of PostgresV2), so it's production ready from our POV. But it's not ready for others, because it's short on documentation (especially user documentation) and it mostly implements stuff we need(ed). That's why there was no announcement about it yet. > > Is there some writeup about this package somewhere ? > No, there's none, but in short: The package consists of a 3 "APIs". The lowest level API is the PG3Connection. This works pretty much like PostgresV2, though some method names are different, but if you know how to use PostgresV2, then you will find out in 5 minutes how to use this. A higher level API is the PG3ConnectionPool which implements a simple connection pool. It's fairly easy to use the pool too. In 10 minutes one can set up a pool for a db without docs. The highest level API (in the public repository) is the PG3FunctionClient which allows you to call Postgres functions which return a refcursor. Most of our apps use this API to communicate with the DB. In our private repo we implemented a new high level API, which allows one to edit the Postgres functions in the Browser, fix bugs in the Debugger, version them with Monticello, etc. It also allows one to call "normal" functions which don't return a refcursor. Since the package is getting fat, we are at the point where we have to split it. When we're done with that, we'll push it to the public repo. So feel free to experiment with it and if you need a feature or found a bug, let us know. Levente > Thx, > > Sven > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 25, 2010

Re: [Pharo-project] DevTools on PharoCore 1.2

by GermÃ¡n Arduino

Sorry, but exist some way of have shout and ocompletion on Core 1.2 ? 2010/8/23 Gary Chambers <gazzaguru2(a)btinternet.com>: > Styling seems to be done in a background process... since with long methods > it may be quite time consuming. > Hence seeing unstyled first then, later, styled text. > > Regards, Gary > > ----- Original Message ----- From: "Schwab,Wilhelm K" > <bschwab(a)anest.ufl.edu> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, August 23, 2010 2:36 PM > Subject: Re: [Pharo-project] DevTools on PharoCore 1.2 > > > I know what you mean. Â I considered using the core at one point. Â It was > surprisingly nice (given its reputation for being minimal), but the lack of > Shout was too much to take :) > > From an efficiency perspective, it is interesting to watch the browser > render a long method: the last time I noticed it, the text rendered in > monochrome and then again in color. Â If Shout is merely tracing back over > the text with color, that might be as intended, but it could also be a clue > to a speed boost if the double-rendering is unintentional. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of GermÃ¡n Arduino > [gsa(a)arsol.net] > Sent: Monday, August 23, 2010 8:06 AM > To: An open mailing list to discuss any topics related to an open-source > Smalltalk > Subject: [Pharo-project] DevTools on PharoCore 1.2 > > Hi! > > How I should install some devtools (at least shout and ocompletion) on > PharoCore to have a more homy work environment? > > I failed with shout, saw some threads about, but can't install it.... > > Thanks. > > -- > ================================================= > GermÃ¡n S. Arduino Â <gsa @ arsol.net> Twitter: garduino > Arduino Software & Web Hosting Â http://www.arduinosoftware.com > PasswordsPro Â http://www.passwordspro.com > ================================================= > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- ================================================= GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com PasswordsProÂ http://www.passwordspro.com =================================================

Aug. 24, 2010

Re: [Pharo-project] String to Number conversion

by Guillermo Polito

I submitted the fix (just removed the "failBlock:[^0]") and some new tests. Name: SLICE-Issue-2857-StringToNumberConversionImprovement-GuillermoPolito.1 Author: GuillermoPolito Time: 24 August 2010, 7:17:42 pm UUID: 53653896-47e9-4451-920f-b8db7198bd06 Ancestors: Dependencies: Kernel-GuillermoPolito.735, KernelTests-GuillermoPolito.280 Number>>readFrom: and Integer>>readFrom: fails when they have to. Improved tests for reading Numbers from Strings On Tue, Aug 24, 2010 at 5:54 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Searching in the mails: > > <quote> > self assert: '123blabla' squeezeOutNumber equals: 123. > self assert: 'blabla123' squeezeOutNumber equals: 123. > self assert: 'blabla12blabla' squeezeOutNumber equals: 12. > self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs < 0.0001. > self assert: '.1' squeezeOutNumber > 0. > </quote> > > I tried it in my image and > > 'bla' squeezeOutNumber. > > fails because of a primitive error... > > Anyway, the behavior is a little different from the existent in #readFrom: > Did you mean to let the dirty stuff to #squeezeOutNumber and throw the > error in the #readFrom:? > > > On Tue, Aug 24, 2010 at 5:49 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> >> >> http://code.google.com/p/pharo/issues/detail?id=2857 >> >> >> >> Which will be the impact in the system and other tools to throw an >> error >> >> when the conversion cannot take place? >> >> I think an error must be thrown, but should it be in Pharo 1.2 or in >> next >> >> version? >> >> >> > >> > My opinion: the system will be more predictible and cleaner ;) >> >> Me too. >> Still this is strange because I'm sure we did that with niko and introduce >> squeeze..... >> So may be we integrated some older code on top. >> I remember that even our changes broke scriptloader itself and the update >> stream :) >> >> > Nicolas >> > >> >> On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier >> >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> >> >>> In squeak, (Integer readFromString: 'foo') ->Error >> >>> >> >>> Use: >> >>> - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, >> >>> - (Integer readFrom: 'foo' ifFail: []), to get nil >> >>> >> >>> Though it is possible, I dislike anwsering nil, because it would mean >> >>> a bunch of #readFrom: send should be protected by #ifNil: Blocks... >> >>> 1) That's nonsense, readFrom:ifFail: already does the work. >> >>> 2) you cripple the code with Error conditions and end up with >> >>> unreadable C-looking like code >> >>> (3 lines of Error condition crap for 1 line of underlying algorithm >> >>> at every function call) >> >>> 3) Exception handling can avoid long chains of ifFail: / ifNil: tests >> >>> >> >>> But that conversation already took place many times... >> >>> >> >>> I'd like the readFrom:ifFail: form to be generalized to other objects, >> >>> with default behaviour raising an Error. What do you think ? >> >>> >> >>> Nicolas >> >>> >> >>> 2010/8/24 Johan Brichau <johan(a)inceptive.be>: >> >>>> >> >>>> On 24 Aug 2010, at 15:19, StÃ©phane Ducasse wrote: >> >>>> >> >>>>> I thought that readFromString: was raising an error and that >> >>>>> guessNumber* was returning zero >> >>>> >> >>>> I thought that too. I even have application code that shows that this >> >>>> used to return nil in some version of Pharo... >> >>>> But: >> >>>> >> >>>> 'foo' asInteger = nil >> >>>> Integer readFromString: 'foo' = 0 >> >>>> 'foo' asNumber -> Error >> >>>> >> >>>> aargh :-( >> >>>> >> >>>> disclaimer: currently testing this in pharo1.1 >> >>>> >> >>>> Johan >> >>>> _______________________________________________ >> >>>> Pharo-project mailing list >> >>>> Pharo-project(a)lists.gforge.inria.fr >> >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >>>> >> >>> >> >>> _______________________________________________ >> >>> Pharo-project mailing list >> >>> Pharo-project(a)lists.gforge.inria.fr >> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Aug. 24, 2010

Re: [Pharo-project] [Pharo-users] funny idea Symbol vs. Selector

by Gabriel Brunstein

?? 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 <siguctua(a)gmail.com> wrote: > On 25 August 2010 00:14, Gabriel Brunstein <gaboto(a)gmail.com> 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 >> <nicolas.cellier.aka.nice(a)gmail.com> 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 <gaboto(a)gmail.com>: >>>> 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 <siguctua(a)gmail.com> wrote: >>>>> 2010/8/24 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>>>> >>>>>> >>>>>> 2010/8/24 Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>>>>> >>>>>>>> On 23 August 2010 23:26, stephane ducasse <stephane.ducasse(a)free.fr> >>>>>>>> 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 >>>>>>>> > Pharo-users(a)lists.gforge.inria.fr >>>>>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Igor Stasenko AKA sig. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-users mailing list >>>>>>>> Pharo-users(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 24, 2010

Re: [Pharo-project] [Pharo-users] funny idea Symbol vs. Selector

by Igor Stasenko

On 25 August 2010 00:23, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> 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 >> > Pharo-users(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Aug. 24, 2010

Re: [Pharo-project] [Pharo-users] funny idea Symbol vs. Selector

by Igor Stasenko

On 25 August 2010 00:14, Gabriel Brunstein <gaboto(a)gmail.com> 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 > <nicolas.cellier.aka.nice(a)gmail.com> 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 <gaboto(a)gmail.com>: >>> 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 <siguctua(a)gmail.com> wrote: >>>> 2010/8/24 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>>> >>>>> >>>>> 2010/8/24 Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>>> >>>>>> >>>>>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>>>> >>>>>>> On 23 August 2010 23:26, stephane ducasse <stephane.ducasse(a)free.fr> >>>>>>> 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 >>>>>>> > Pharo-users(a)lists.gforge.inria.fr >>>>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>>> > >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Stasenko AKA sig. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-users mailing list >>>>>>> Pharo-users(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Aug. 24, 2010

Re: [Pharo-project] PackageInfo >> printOn:

by StÃ©phane Ducasse

You remember when we tried to tag all senders and implementors result with a package (because I need this information when trying to get throw the junggle) and I thought that the printOn: could remind such notation. Now probably this solution is better/ Stef > I would change it to > > PackageInfo>>printOn: aStream > aStream print: self class; nextPutAll: ' named: '; print: self packageName > > That's basically the only solution that really makes sense. > > Lukas > > On 24 August 2010 22:50, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> may be { Collections-Weak } to make a displayed sign to denote packages. >> >> Stef >> >>> Or maybe we can add >>> >>> PackageInfo >> name >>> ^ self packageName >>> >>> >>> >>> >>> On Tue, Aug 24, 2010 at 4:54 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> Hi. The current implementation of PackageInfo >> printOn: is this: >>> >>> printOn: aStream >>> >>> super printOn: aStream. >>> aStream nextPutAll: '(',self packageName,')'. >>> >>> So...it prints something like this: 'aPackageInfo(Collections-Weak)' >>> >>> most of the times I prefer to print 'Collections-Weak' >>> >>> in my image I change it to >>> >>> printOn: aStream >>> >>> aStream nextPutAll: self packageName. >>> >>> Do you think this can be useful for the rest or I just keep it in my image? >>> >>> Cheers >>> >>> Mariano >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 24, 2010