August 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Why String>>adaptToNumber: rcvr andSend: selector

by Guillermo Polito

Well Collection and Point understand that message too. One step at a time, but an issue entry now so we don't forget about it. http://code.google.com/p/pharo/issues/detail?id=2858 On Tue, Aug 24, 2010 at 5:20 PM, Carla F. Griggio <carla.griggio(a)gmail.com>wrote: > What we've been discussing with Guille is that sometimes the 'type > checking' (or actually, the conversion) is done, and sometimes not. > > For example: > > 5 + true > > true does not understand 'adaptToNumber:andSend:', so no magic conversion > is done, but strings understand that message so we get things like: > > 5 + 'foo' = 5 > > This should be consistent regardless the type of the parameter. > > Cheers, > Carla > > > > On Tue, Aug 24, 2010 at 5:10 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Do we reeeeeally want to do >> >> 5 + '4' >> >> 5 + 'hello' >> >> ? >> > >

Aug. 24, 2010

Re: [Pharo-project] String to Number conversion

by StÃ©phane Ducasse

did you check because with niko scwarz during the sprint at lille we discussed about squeezeNumberOutOfString: Stef On Aug 24, 2010, at 10:33 PM, Guillermo Polito 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? > > 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

Aug. 24, 2010

Re: [Pharo-project] String to Number conversion

by Nicolas Cellier

2010/8/24 Guillermo Polito <guillermopolito(a)gmail.com>: > 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 ;) 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 >

Aug. 24, 2010

Re: [Pharo-project] Why String>>adaptToNumber: rcvr andSend: selector

by Nicolas Cellier

There are two superposed problems there 1) let String auto convert to Number when implied in arithmetic 2) let any malformed String asNumber answer zero To my sense, both features: * are not really necessary nor worth * are a source of problems * should better be removed. Nicolas 2010/8/24 Carla F. Griggio <carla.griggio(a)gmail.com>: > What we've been discussing with Guille is that sometimes the 'type checking' > (or actually, the conversion) is done, and sometimes not. > > For example: > > 5 + true > > true does not understand 'adaptToNumber:andSend:', so no magic conversion is > done, but strings understand that message so we get things like: > > 5 + 'foo' = 5 > > This should be consistent regardless the type of the parameter. > > Cheers, > Carla > > > On Tue, Aug 24, 2010 at 5:10 PM, Guillermo Polito > <guillermopolito(a)gmail.com> wrote: >> >> Do we reeeeeally want to do >> >> 5 + '4' >> >> 5 + 'hello' >> >> ? > > > _______________________________________________ > 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

[Pharo-project] String to Number conversion

by Guillermo Polito

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? 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 >

Aug. 24, 2010

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

by Nicolas Cellier

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 >

Aug. 24, 2010

Re: [Pharo-project] Why String>>adaptToNumber: rcvr andSend: selector

by Carla F. Griggio

What we've been discussing with Guille is that sometimes the 'type checking' (or actually, the conversion) is done, and sometimes not. For example: 5 + true true does not understand 'adaptToNumber:andSend:', so no magic conversion is done, but strings understand that message so we get things like: 5 + 'foo' = 5 This should be consistent regardless the type of the parameter. Cheers, Carla On Tue, Aug 24, 2010 at 5:10 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Do we reeeeeally want to do > > 5 + '4' > > 5 + 'hello' > > ? >

Aug. 24, 2010

Re: [Pharo-project] Why String>>adaptToNumber: rcvr andSend: selector

by Nicolas Cellier

Noooo, we dooon't want to. Nicolas 2010/8/24 Guillermo Polito <guillermopolito(a)gmail.com>: > Do we reeeeeally want to do > > 5 + '4' > > 5 + 'hello' > > ? > > _______________________________________________ > 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

[Pharo-project] Why String>>adaptToNumber: rcvr andSend: selector

by Guillermo Polito

Do we reeeeeally want to do 5 + '4' 5 + 'hello' ?

Aug. 24, 2010

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

by Gabriel Brunstein

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

Aug. 24, 2010