- Pharo-dev - lists.pharo.org

[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

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

by Igor Stasenko

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.

Aug. 24, 2010

Re: [Pharo-project] [Fixed]: Issue 2856: Use unique URL to core from [Dev image]->World Menu->System>Software update

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > thanks! > Absolutely, and no thanks necessary - it's my Pharo, too! Sean -- View this message in context: http://forum.world.st/Fixed-Issue-2856-Use-unique-URL-to-core-from-Dev-imag… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 24, 2010

Re: [Pharo-project] [Fixed]: Issue 2856: Use unique URL to core from [Dev image]->World Menu->System>Software update

by StÃ©phane Ducasse

thanks! STef On Aug 24, 2010, at 8:36 PM, Sean P. DeNigris wrote: > > http://code.google.com/p/pharo/issues/detail?id=2856 > > In a 1.2 dev image, when a user chooses System>Software update, they see a > dialog explaining how to get an updatable (i.e. core trunk) image (issue ). > This link should be the unique URL that was just set up - > http://www.pharo-project.org/pharo-download/unstable-core. > > Fix in PharoInbox: > SLICE-Issue-2856-DevSoftwareUpdateShowsUnqiueCoreURL-SeanDeNigris.1 > > Sean > -- > View this message in context: http://forum.world.st/Fixed-Issue-2856-Use-unique-URL-to-core-from-Dev-imag… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > 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] [update 1.2] #12106

by StÃ©phane Ducasse

blue and wide :) >> Luc and i restarted working on Ocean last week after vacation. We moved to 1.1 and improved socket a bit. >> I'll carry on with the socket chapter too :-) > > In one sentence, what is Ocean? > > Alexandre

Aug. 24, 2010