- Pharo-users - lists.pharo.org

Re: [Pharo-users] How to have an in-image map (morph/spec/brick) showing a gps location

by Richard Sargent

Beautiful, Sven! I have a publicity suggestion. Make a larger png of that and share it on Twitter and LinkedIn. (And if you do, I would also suggest cascading the message sends to the camera.) I would love to share that around! On Sun, Feb 11, 2018 at 12:26 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 10 Feb 2018, at 19:00, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > Sven in Roassal you can see them in the examples menu. > > > Ah, and it all works out-of-the-box just-like-that in > Pharo-7.0+alpha.build.493.sha.d53a70bc946ed83b046f61ac35f00c67fa77269a > (32 Bit) on macOS. > > > Wow, amazing ! Very, very nice. > > On Fri, Feb 9, 2018 at 10:20 AM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > > Thanks all, > > Iâll give a try to roassal so. > > Cheers, > > Cedrick > > Le 9 fÃ©vr. 2018 Ã 08:59, Thierry Goubier <thierry.goubier(a)gmail.com> a > Ã©crit : > > 2018-02-09 7:50 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 9 Feb 2018, at 06:40, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > Le 09/02/2018 Ã 00:46, Arturo Zambrano a Ã©crit : > > I used Roassal + OSM and worked perfectly (2 year ago at least). Although > I think there is no support for something like a tiles cache. > > > We did the OSM support with an in-image tiles cache, but limited to the > current map section being viewed. > > It would be easy to add an on-disk cache to that code. > > Thierry > > On Thu, Feb 8, 2018 at 7:46 AM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com < > mailto:cdrick65@gmail.com <cdrick65(a)gmail.com>>> wrote: > Hello, > I would like to have a representation of a map in the image to show > (my) GPS coordinates. > I havenât really tried nor searched yet but Iâve seen Roassal > examples that could do the job, especially the Open Street Map > integration. > So does people here have advices on how to to that (having a morph > that shows a map and positions) ? > Ideally I would like to have it work offline (meaning I download > first tilesâ¦or a vectorized map would do the job too). > TIA, > CÃ©drick > > > Thierry, > > Where are the load instructions ? Does it still work for Pharo 7 ? > > > It should still be part of Roassal, with some issues with the data > sources used to retrieve cities coordinates (they went offline!). > > I haven't started working with Pharo 7 yet, so I can't say. > > Thierry > > Sven > > > > > > >

Feb. 11, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by Denis Kudriashov

2018-02-11 21:08 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Denis > > we should introduce classNamed: now we can have traits and globals too :( > Yes, we need to think about it. > Idea? may be can still classNamed: > > Stef > > > On Sun, Feb 11, 2018 at 8:55 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > > > > 2018-02-11 20:36 GMT+01:00 HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com>: > >> > >> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> > Hi Hernan. > >> > > >> > 2018-02-11 19:57 GMT+01:00 HernÃ¡n Morales Durand > >> > <hernan.morales(a)gmail.com>: > >> >> > >> >> Hi Denis > >> >> > >> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> > > >> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse > >> >> > <stepharo.self(a)gmail.com>: > >> >> >> > >> >> >> Please to not use an unary on Symbol > >> >> >> Dispatch on something. > >> >> >> > >> >> >> self class environment at: #Array > >> >> >> is the best > >> >> > > >> >> > > >> >> > We should not use collection API for reflection calls. It makes > them > >> >> > very > >> >> > difficult to find. Let's use explicit names like: > >> >> > > >> >> > >> >> Sorry I do not see it. > >> >> > >> >> The Collection API is beautiful, why couldn't be used for reflection? > >> > > >> > > >> > We have around 3000 senders of #at: message in the image. Do you think > >> > it is > >> > easy to filter reflective calls? > >> > > >> > >> I still don't understand your use case, nor how the #at: is related > >> with the #asClass issue. > >> > >> Do you mean **further** filtering for relflective sends? > >> > >> Does this affects common-usage beyond Browser development? > > > > > > The Stef proposal was that we should never use #asClass in the code. It > is > > fine for scripting but not for the domain code by many reasons which were > > discussed here and at the past. > > > > But I only commented the proposed replacement: > > > > self class environment at: #Object > > > > > > If you do not like it, it is different story. I just described problem > with > > #at: message: > > > > We already replaced many #asClass users with this code. And now it is > quite > > difficult to find such places. They all hidden inside 3000 senders of > #at:. > > If we will use #classNamed: instead of #at: then simple senders query > will > > easily detect all reflective calls. > > (we probably already use it but not in all places). > > > >> > >> > >> >> > >> >> I have no trouble finding #asClass senders, implementors, etc. > >> >> > >> >> What do you want to find? > >> >> > >> >> > self class environment classNamed: #Array > >> >> > > >> >> > >> >> Too much typing :) > >> >> > >> >> > > >> >> > From the other side we all agree that #asClass is super handy > method. > >> >> > And we > >> >> > can fix it to respect sender environment using thisContext. It will > >> >> > affects > >> >> > performance but with our super powerful metalinks it can be easily > >> >> > cached > >> >> > (#asMethodConst is implemented that way). > >> >> > So we can make environment completely transparent for users. > >> >> > > >> >> > Best regards, > >> >> > Denis > >> >> > > >> >> >> > >> >> >> For Modules, we made progress and got bitten by many issues and > >> >> >> teaching > >> >> >> load. > >> >> >> > >> >> >> > >> >> >> Stef > >> >> >> > >> >> >> On Sat, Feb 10, 2018 at 4:50 PM, ClÃ©ment Bera > >> >> >> <bera.clement(a)gmail.com> > >> >> >> wrote: > >> >> >> > On Sat, Feb 10, 2018 at 4:34 PM, HernÃ¡n Morales Durand > >> >> >> > <hernan.morales(a)gmail.com> wrote: > >> >> >> >> > >> >> >> >> Hi ClÃ©ment, > >> >> >> >> > >> >> >> >> First time I read about modules in Pharo. > >> >> >> >> What is a module exactly? > >> >> >> >> > >> >> >> >> What's the problem to solve? > >> >> >> > > >> >> >> > > >> >> >> > It's similar to namespaces with some different, arguably better, > >> >> >> > features. > >> >> >> > > >> >> >> > Honestly I am not the expert on it so I would like some one else > >> >> >> > to > >> >> >> > answer. > >> >> >> > > >> >> >> > Among other things, it solves the problem of having 2 classes > with > >> >> >> > the > >> >> >> > same > >> >> >> > name (avoiding the prefixes we have like in C). But reportedly > >> >> >> > that's > >> >> >> > just a > >> >> >> > side-effect and not the main problem to solve. > >> >> >> > > >> >> >> >> > >> >> >> >> Cheers, > >> >> >> >> > >> >> >> >> HernÃ¡n > >> >> >> >> > >> >> >> >> 2018-02-10 9:47 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com > >: > >> >> >> >> > Hi, > >> >> >> >> > > >> >> >> >> > In short, everything that is not namespace/module compatible > >> >> >> >> > will > >> >> >> >> > be > >> >> >> >> > deprecated/changed/removed in the future, so it is not > >> >> >> >> > recommended > >> >> >> >> > to > >> >> >> >> > use > >> >> >> >> > it. > >> >> >> >> > > >> >> >> >> > a.2) #Array asClassInEnvironment: Smalltalk globals > >> >> >> >> > b.1) Smalltalk globals at: #Array > >> >> >> >> > => Ok-ish, note that you may need to change 'Smalltalk > globals' > >> >> >> >> > the > >> >> >> >> > namespace/module when support for those will be added since > >> >> >> >> > Array > >> >> >> >> > will > >> >> >> >> > be in > >> >> >> >> > a module. > >> >> >> >> > Maybe you want instead to use instead: > >> >> >> >> > > >> >> >> >> > c) self class environment at: #Array > >> >> >> >> > => this will work in the future if your code is a class which > >> >> >> >> > environment/namespace/module includes the Array class you > would > >> >> >> >> > expect > >> >> >> >> > > >> >> >> >> > a.1) #Array asClass > >> >> >> >> > b.2) Smalltalk at: #Array > >> >> >> >> > b.3) Smalltalk classNamed: #Array > >> >> >> >> > => In which namespace/module are you looking for #Array ? In > >> >> >> >> > the > >> >> >> >> > future > >> >> >> >> > this > >> >> >> >> > may be removed, alternatively it will work only for globals > but > >> >> >> >> > not > >> >> >> >> > globals > >> >> >> >> > inside namespace/module which won't work since Array will be > in > >> >> >> >> > a > >> >> >> >> > module. > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > On Sat, Feb 10, 2018 at 12:57 PM, Peter UhnÃ¡k > >> >> >> >> > <i.uhnak(a)gmail.com> > >> >> >> >> > wrote: > >> >> >> >> >> > >> >> >> >> >> Hi, > >> >> >> >> >> > >> >> >> >> >> what is the canonical way to get a class from a symbol? > >> >> >> >> >> > >> >> >> >> >> a) Converting symbol into class via string protocol > >> >> >> >> >> > >> >> >> >> >> a.1) #Array asClass > >> >> >> >> >> I use this the most, because it is easy, uses unary > selector, > >> >> >> >> >> and > >> >> >> >> >> so > >> >> >> >> >> far > >> >> >> >> >> I've never ran into any issues. But apparently it is not > good > >> >> >> >> >> -- > >> >> >> >> >> why? > >> >> >> >> >> > >> >> >> >> >> a.2) #Array asClassInEnvironment: Smalltalk globals > >> >> >> >> >> > >> >> >> >> >> b) Retriving the class by key from the system dictionary > >> >> >> >> >> > >> >> >> >> >> b.1) Smalltalk globals at: #Array > >> >> >> >> >> > >> >> >> >> >> b.2) Smalltalk at: #Array > >> >> >> >> >> > >> >> >> >> >> b.3) Smalltalk classNamed: #Array > >> >> >> >> >> > >> >> >> >> >> c) something else entirely? > >> >> >> >> >> > >> >> >> >> >> I get that using #asClass wouldn't work if there was a > >> >> >> >> >> different > >> >> >> >> >> environment, however I don't even know in what situation > there > >> >> >> >> >> could > >> >> >> >> >> be > >> >> >> >> >> a > >> >> >> >> >> different environment, so I cannot assert how problematic it > >> >> >> >> >> is > >> >> >> >> >> or > >> >> >> >> >> isn't. > >> >> >> >> >> > >> >> >> >> >> Thanks, > >> >> >> >> >> Peter > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > -- > >> >> >> >> > ClÃ©ment BÃ©ra > >> >> >> >> > Pharo consortium engineer > >> >> >> >> > https://clementbera.wordpress.com/ > >> >> >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > -- > >> >> >> > ClÃ©ment BÃ©ra > >> >> >> > Pharo consortium engineer > >> >> >> > https://clementbera.wordpress.com/ > >> >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > >> >> >> > >> >> > > >> >> > >> > > >> > > > >

Feb. 11, 2018

Re: [Pharo-users] Object configuration idioms

by Stephane Ducasse

Arghhhhhh no magic please. I got burned by too much DNU override. On Sun, Feb 11, 2018 at 8:17 PM, Christian Caldeiro <christian.caldeiro(a)gmail.com> wrote: > Maybe using directly TwitterClient, but using #doesNotUnderstand: to > delegate there message sends to the configuration object(kind of a proxy > pattern). That way the TwitterClient class doesn't became so heavy. > > Christian > > > > On Sun, Feb 11, 2018 at 1:35 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Why not directly on TwitterClient ? That would be easiest for the user, >> then they do not need to know about TwitterConfiguration. Anyway, that is >> how I do it most often. The disadvantage is that TwitterClient might become >> a bit heavy, API wise, but you can delegate internally. >> >> > On 11 Feb 2018, at 16:25, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> > >> > Hi, >> > >> > are there any best practices/idioms in regards to object >> > configuration/building? >> > >> > Let's say I want to configure a TwitterClient that requires a username >> > and a password that is stored in a separate object TwitterConfiguration >> > >> > a) the basic approach (either separate sends or via cascade, that is not >> > relevant here) >> > >> > client := TwitterClient new. >> > client configuration username: 'XX'. >> > client configuration password: 'YY'. >> > >> > >> > b) #in: ... >> > >> > It feels a bit more organized as it basically groups related operations >> > together. >> > Also maybe avoiding demeter a bit? >> > >> > client := TwitterClient new. >> > client configuration in: [ :config | >> > config username: 'XX'. >> > config password: 'YY'. >> > ]. >> > >> > c) custom #somethingDo: method that basically does #in: >> > >> > Again, feels more organized. Additionally one could perform some >> > validation afterwards (to make sure the credentials are ok or whatever). >> > >> > client := TwitterClient new. >> > client configurationDo: [ :config | >> > config username: 'XX'. >> > config password: 'YY' >> > ]. >> > >> > Any thoughts on this? >> > >> > Thanks, >> > Peter >> >> >

Feb. 11, 2018

Re: [Pharo-users] How to have an in-image map (morph/spec/brick) showing a gps location

by Stephane Ducasse

Nice city in addition I love Quartin Latin :) On Sun, Feb 11, 2018 at 9:26 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 10 Feb 2018, at 19:00, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > Sven in Roassal you can see them in the examples menu. > > > Ah, and it all works out-of-the-box just-like-that in > Pharo-7.0+alpha.build.493.sha.d53a70bc946ed83b046f61ac35f00c67fa77269a > (32 Bit) on macOS. > > > Wow, amazing ! Very, very nice. > > On Fri, Feb 9, 2018 at 10:20 AM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > > Thanks all, > > Iâll give a try to roassal so. > > Cheers, > > Cedrick > > Le 9 fÃ©vr. 2018 Ã 08:59, Thierry Goubier <thierry.goubier(a)gmail.com> a > Ã©crit : > > 2018-02-09 7:50 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 9 Feb 2018, at 06:40, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > Le 09/02/2018 Ã 00:46, Arturo Zambrano a Ã©crit : > > I used Roassal + OSM and worked perfectly (2 year ago at least). Although > I think there is no support for something like a tiles cache. > > > We did the OSM support with an in-image tiles cache, but limited to the > current map section being viewed. > > It would be easy to add an on-disk cache to that code. > > Thierry > > On Thu, Feb 8, 2018 at 7:46 AM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com < > mailto:cdrick65@gmail.com <cdrick65(a)gmail.com>>> wrote: > Hello, > I would like to have a representation of a map in the image to show > (my) GPS coordinates. > I havenât really tried nor searched yet but Iâve seen Roassal > examples that could do the job, especially the Open Street Map > integration. > So does people here have advices on how to to that (having a morph > that shows a map and positions) ? > Ideally I would like to have it work offline (meaning I download > first tilesâ¦or a vectorized map would do the job too). > TIA, > CÃ©drick > > > Thierry, > > Where are the load instructions ? Does it still work for Pharo 7 ? > > > It should still be part of Roassal, with some issues with the data > sources used to retrieve cities coordinates (they went offline!). > > I haven't started working with Pharo 7 yet, so I can't say. > > Thierry > > Sven > > > > > > >

Feb. 11, 2018

Re: [Pharo-users] How to have an in-image map (morph/spec/brick) showing a gps location

by Sven Van Caekenberghe

> On 10 Feb 2018, at 19:00, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Sven in Roassal you can see them in the examples menu. Ah, and it all works out-of-the-box just-like-that in Pharo-7.0+alpha.build.493.sha.d53a70bc946ed83b046f61ac35f00c67fa77269a (32 Bit) on macOS. Wow, amazing ! Very, very nice. > On Fri, Feb 9, 2018 at 10:20 AM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: >> Thanks all, >> >> Iâll give a try to roassal so. >> >> Cheers, >> >> Cedrick >> >>> Le 9 fÃ©vr. 2018 Ã 08:59, Thierry Goubier <thierry.goubier(a)gmail.com> a Ã©crit : >>> >>> 2018-02-09 7:50 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>> >>>> >>>>> On 9 Feb 2018, at 06:40, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>>>> >>>>> Le 09/02/2018 Ã 00:46, Arturo Zambrano a Ã©crit : >>>>>> I used Roassal + OSM and worked perfectly (2 year ago at least). Although I think there is no support for something like a tiles cache. >>>>> >>>>> We did the OSM support with an in-image tiles cache, but limited to the current map section being viewed. >>>>> >>>>> It would be easy to add an on-disk cache to that code. >>>>> >>>>> Thierry >>>>> >>>>>> On Thu, Feb 8, 2018 at 7:46 AM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com <mailto:cdrick65@gmail.com>> wrote: >>>>>> Hello, >>>>>> I would like to have a representation of a map in the image to show >>>>>> (my) GPS coordinates. >>>>>> I havenât really tried nor searched yet but Iâve seen Roassal >>>>>> examples that could do the job, especially the Open Street Map >>>>>> integration. >>>>>> So does people here have advices on how to to that (having a morph >>>>>> that shows a map and positions) ? >>>>>> Ideally I would like to have it work offline (meaning I download >>>>>> first tilesâ¦or a vectorized map would do the job too). >>>>>> TIA, >>>>>> CÃ©drick >>>> >>>> Thierry, >>>> >>>> Where are the load instructions ? Does it still work for Pharo 7 ? >>> >>> It should still be part of Roassal, with some issues with the data >>> sources used to retrieve cities coordinates (they went offline!). >>> >>> I haven't started working with Pharo 7 yet, so I can't say. >>> >>> Thierry >>> >>>> Sven >>>> >>>> >>> >> >

Feb. 11, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by HernÃ¡n Morales Durand

2018-02-11 16:55 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > > 2018-02-11 20:36 GMT+01:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: >> >> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> > Hi Hernan. >> > >> > 2018-02-11 19:57 GMT+01:00 HernÃ¡n Morales Durand >> > <hernan.morales(a)gmail.com>: >> >> >> >> Hi Denis >> >> >> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> > >> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse >> >> > <stepharo.self(a)gmail.com>: >> >> >> >> >> >> Please to not use an unary on Symbol >> >> >> Dispatch on something. >> >> >> >> >> >> self class environment at: #Array >> >> >> is the best >> >> > >> >> > >> >> > We should not use collection API for reflection calls. It makes them >> >> > very >> >> > difficult to find. Let's use explicit names like: >> >> > >> >> >> >> Sorry I do not see it. >> >> >> >> The Collection API is beautiful, why couldn't be used for reflection? >> > >> > >> > We have around 3000 senders of #at: message in the image. Do you think >> > it is >> > easy to filter reflective calls? >> > >> >> I still don't understand your use case, nor how the #at: is related >> with the #asClass issue. >> >> Do you mean **further** filtering for relflective sends? >> >> Does this affects common-usage beyond Browser development? > > > The Stef proposal was that we should never use #asClass in the code. It is > fine for scripting but not for the domain code by many reasons which were > discussed here and at the past. Maybe it's too drastic not using any unary on Symbol. There are a lot right now: #asIcon, #asMutator, #asSlot, #asString, #isDoIt, #senders, etc. without counting those from String and up. I will check for the past discussion. > > But I only commented the proposed replacement: > > self class environment at: #Object > > > If you do not like it, it is different story. I just described problem with > #at: message: > It's not a problem of like ir or not. It's about future migration effort for issues which maybe are not so common. > We already replaced many #asClass users with this code. And now it is quite > difficult to find such places. They all hidden inside 3000 senders of #at:. > If we will use #classNamed: instead of #at: then simple senders query will > easily detect all reflective calls. > (we probably already use it but not in all places). > Ok, thanks for the clarification. Cheers, HernÃ¡n >> >> >> >> >> >> I have no trouble finding #asClass senders, implementors, etc. >> >> >> >> What do you want to find? >> >> >> >> > self class environment classNamed: #Array >> >> > >> >> >> >> Too much typing :) >> >> >> >> > >> >> > From the other side we all agree that #asClass is super handy method. >> >> > And we >> >> > can fix it to respect sender environment using thisContext. It will >> >> > affects >> >> > performance but with our super powerful metalinks it can be easily >> >> > cached >> >> > (#asMethodConst is implemented that way). >> >> > So we can make environment completely transparent for users. >> >> > >> >> > Best regards, >> >> > Denis >> >> > >> >> >> >> >> >> For Modules, we made progress and got bitten by many issues and >> >> >> teaching >> >> >> load. >> >> >> >> >> >> >> >> >> Stef >> >> >> >> >> >> On Sat, Feb 10, 2018 at 4:50 PM, ClÃ©ment Bera >> >> >> <bera.clement(a)gmail.com> >> >> >> wrote: >> >> >> > On Sat, Feb 10, 2018 at 4:34 PM, HernÃ¡n Morales Durand >> >> >> > <hernan.morales(a)gmail.com> wrote: >> >> >> >> >> >> >> >> Hi ClÃ©ment, >> >> >> >> >> >> >> >> First time I read about modules in Pharo. >> >> >> >> What is a module exactly? >> >> >> >> >> >> >> >> What's the problem to solve? >> >> >> > >> >> >> > >> >> >> > It's similar to namespaces with some different, arguably better, >> >> >> > features. >> >> >> > >> >> >> > Honestly I am not the expert on it so I would like some one else >> >> >> > to >> >> >> > answer. >> >> >> > >> >> >> > Among other things, it solves the problem of having 2 classes with >> >> >> > the >> >> >> > same >> >> >> > name (avoiding the prefixes we have like in C). But reportedly >> >> >> > that's >> >> >> > just a >> >> >> > side-effect and not the main problem to solve. >> >> >> > >> >> >> >> >> >> >> >> Cheers, >> >> >> >> >> >> >> >> HernÃ¡n >> >> >> >> >> >> >> >> 2018-02-10 9:47 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >> >> >> > Hi, >> >> >> >> > >> >> >> >> > In short, everything that is not namespace/module compatible >> >> >> >> > will >> >> >> >> > be >> >> >> >> > deprecated/changed/removed in the future, so it is not >> >> >> >> > recommended >> >> >> >> > to >> >> >> >> > use >> >> >> >> > it. >> >> >> >> > >> >> >> >> > a.2) #Array asClassInEnvironment: Smalltalk globals >> >> >> >> > b.1) Smalltalk globals at: #Array >> >> >> >> > => Ok-ish, note that you may need to change 'Smalltalk globals' >> >> >> >> > the >> >> >> >> > namespace/module when support for those will be added since >> >> >> >> > Array >> >> >> >> > will >> >> >> >> > be in >> >> >> >> > a module. >> >> >> >> > Maybe you want instead to use instead: >> >> >> >> > >> >> >> >> > c) self class environment at: #Array >> >> >> >> > => this will work in the future if your code is a class which >> >> >> >> > environment/namespace/module includes the Array class you would >> >> >> >> > expect >> >> >> >> > >> >> >> >> > a.1) #Array asClass >> >> >> >> > b.2) Smalltalk at: #Array >> >> >> >> > b.3) Smalltalk classNamed: #Array >> >> >> >> > => In which namespace/module are you looking for #Array ? In >> >> >> >> > the >> >> >> >> > future >> >> >> >> > this >> >> >> >> > may be removed, alternatively it will work only for globals but >> >> >> >> > not >> >> >> >> > globals >> >> >> >> > inside namespace/module which won't work since Array will be in >> >> >> >> > a >> >> >> >> > module. >> >> >> >> > >> >> >> >> > >> >> >> >> > On Sat, Feb 10, 2018 at 12:57 PM, Peter UhnÃ¡k >> >> >> >> > <i.uhnak(a)gmail.com> >> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> >> >> what is the canonical way to get a class from a symbol? >> >> >> >> >> >> >> >> >> >> a) Converting symbol into class via string protocol >> >> >> >> >> >> >> >> >> >> a.1) #Array asClass >> >> >> >> >> I use this the most, because it is easy, uses unary selector, >> >> >> >> >> and >> >> >> >> >> so >> >> >> >> >> far >> >> >> >> >> I've never ran into any issues. But apparently it is not good >> >> >> >> >> -- >> >> >> >> >> why? >> >> >> >> >> >> >> >> >> >> a.2) #Array asClassInEnvironment: Smalltalk globals >> >> >> >> >> >> >> >> >> >> b) Retriving the class by key from the system dictionary >> >> >> >> >> >> >> >> >> >> b.1) Smalltalk globals at: #Array >> >> >> >> >> >> >> >> >> >> b.2) Smalltalk at: #Array >> >> >> >> >> >> >> >> >> >> b.3) Smalltalk classNamed: #Array >> >> >> >> >> >> >> >> >> >> c) something else entirely? >> >> >> >> >> >> >> >> >> >> I get that using #asClass wouldn't work if there was a >> >> >> >> >> different >> >> >> >> >> environment, however I don't even know in what situation there >> >> >> >> >> could >> >> >> >> >> be >> >> >> >> >> a >> >> >> >> >> different environment, so I cannot assert how problematic it >> >> >> >> >> is >> >> >> >> >> or >> >> >> >> >> isn't. >> >> >> >> >> >> >> >> >> >> Thanks, >> >> >> >> >> Peter >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > -- >> >> >> >> > ClÃ©ment BÃ©ra >> >> >> >> > Pharo consortium engineer >> >> >> >> > https://clementbera.wordpress.com/ >> >> >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq >> >> >> >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > ClÃ©ment BÃ©ra >> >> >> > Pharo consortium engineer >> >> >> > https://clementbera.wordpress.com/ >> >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq >> >> >> >> >> > >> >> >> > >> >

Feb. 11, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by Stephane Ducasse

Denis we should introduce classNamed: now we can have traits and globals too :( Idea? may be can still classNamed: Stef On Sun, Feb 11, 2018 at 8:55 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2018-02-11 20:36 GMT+01:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: >> >> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> > Hi Hernan. >> > >> > 2018-02-11 19:57 GMT+01:00 HernÃ¡n Morales Durand >> > <hernan.morales(a)gmail.com>: >> >> >> >> Hi Denis >> >> >> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> > >> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse >> >> > <stepharo.self(a)gmail.com>: >> >> >> >> >> >> Please to not use an unary on Symbol >> >> >> Dispatch on something. >> >> >> >> >> >> self class environment at: #Array >> >> >> is the best >> >> > >> >> > >> >> > We should not use collection API for reflection calls. It makes them >> >> > very >> >> > difficult to find. Let's use explicit names like: >> >> > >> >> >> >> Sorry I do not see it. >> >> >> >> The Collection API is beautiful, why couldn't be used for reflection? >> > >> > >> > We have around 3000 senders of #at: message in the image. Do you think >> > it is >> > easy to filter reflective calls? >> > >> >> I still don't understand your use case, nor how the #at: is related >> with the #asClass issue. >> >> Do you mean **further** filtering for relflective sends? >> >> Does this affects common-usage beyond Browser development? > > > The Stef proposal was that we should never use #asClass in the code. It is > fine for scripting but not for the domain code by many reasons which were > discussed here and at the past. > > But I only commented the proposed replacement: > > self class environment at: #Object > > > If you do not like it, it is different story. I just described problem with > #at: message: > > We already replaced many #asClass users with this code. And now it is quite > difficult to find such places. They all hidden inside 3000 senders of #at:. > If we will use #classNamed: instead of #at: then simple senders query will > easily detect all reflective calls. > (we probably already use it but not in all places). > >> >> >> >> >> >> I have no trouble finding #asClass senders, implementors, etc. >> >> >> >> What do you want to find? >> >> >> >> > self class environment classNamed: #Array >> >> > >> >> >> >> Too much typing :) >> >> >> >> > >> >> > From the other side we all agree that #asClass is super handy method. >> >> > And we >> >> > can fix it to respect sender environment using thisContext. It will >> >> > affects >> >> > performance but with our super powerful metalinks it can be easily >> >> > cached >> >> > (#asMethodConst is implemented that way). >> >> > So we can make environment completely transparent for users. >> >> > >> >> > Best regards, >> >> > Denis >> >> > >> >> >> >> >> >> For Modules, we made progress and got bitten by many issues and >> >> >> teaching >> >> >> load. >> >> >> >> >> >> >> >> >> Stef >> >> >> >> >> >> On Sat, Feb 10, 2018 at 4:50 PM, ClÃ©ment Bera >> >> >> <bera.clement(a)gmail.com> >> >> >> wrote: >> >> >> > On Sat, Feb 10, 2018 at 4:34 PM, HernÃ¡n Morales Durand >> >> >> > <hernan.morales(a)gmail.com> wrote: >> >> >> >> >> >> >> >> Hi ClÃ©ment, >> >> >> >> >> >> >> >> First time I read about modules in Pharo. >> >> >> >> What is a module exactly? >> >> >> >> >> >> >> >> What's the problem to solve? >> >> >> > >> >> >> > >> >> >> > It's similar to namespaces with some different, arguably better, >> >> >> > features. >> >> >> > >> >> >> > Honestly I am not the expert on it so I would like some one else >> >> >> > to >> >> >> > answer. >> >> >> > >> >> >> > Among other things, it solves the problem of having 2 classes with >> >> >> > the >> >> >> > same >> >> >> > name (avoiding the prefixes we have like in C). But reportedly >> >> >> > that's >> >> >> > just a >> >> >> > side-effect and not the main problem to solve. >> >> >> > >> >> >> >> >> >> >> >> Cheers, >> >> >> >> >> >> >> >> HernÃ¡n >> >> >> >> >> >> >> >> 2018-02-10 9:47 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >> >> >> > Hi, >> >> >> >> > >> >> >> >> > In short, everything that is not namespace/module compatible >> >> >> >> > will >> >> >> >> > be >> >> >> >> > deprecated/changed/removed in the future, so it is not >> >> >> >> > recommended >> >> >> >> > to >> >> >> >> > use >> >> >> >> > it. >> >> >> >> > >> >> >> >> > a.2) #Array asClassInEnvironment: Smalltalk globals >> >> >> >> > b.1) Smalltalk globals at: #Array >> >> >> >> > => Ok-ish, note that you may need to change 'Smalltalk globals' >> >> >> >> > the >> >> >> >> > namespace/module when support for those will be added since >> >> >> >> > Array >> >> >> >> > will >> >> >> >> > be in >> >> >> >> > a module. >> >> >> >> > Maybe you want instead to use instead: >> >> >> >> > >> >> >> >> > c) self class environment at: #Array >> >> >> >> > => this will work in the future if your code is a class which >> >> >> >> > environment/namespace/module includes the Array class you would >> >> >> >> > expect >> >> >> >> > >> >> >> >> > a.1) #Array asClass >> >> >> >> > b.2) Smalltalk at: #Array >> >> >> >> > b.3) Smalltalk classNamed: #Array >> >> >> >> > => In which namespace/module are you looking for #Array ? In >> >> >> >> > the >> >> >> >> > future >> >> >> >> > this >> >> >> >> > may be removed, alternatively it will work only for globals but >> >> >> >> > not >> >> >> >> > globals >> >> >> >> > inside namespace/module which won't work since Array will be in >> >> >> >> > a >> >> >> >> > module. >> >> >> >> > >> >> >> >> > >> >> >> >> > On Sat, Feb 10, 2018 at 12:57 PM, Peter UhnÃ¡k >> >> >> >> > <i.uhnak(a)gmail.com> >> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> >> >> what is the canonical way to get a class from a symbol? >> >> >> >> >> >> >> >> >> >> a) Converting symbol into class via string protocol >> >> >> >> >> >> >> >> >> >> a.1) #Array asClass >> >> >> >> >> I use this the most, because it is easy, uses unary selector, >> >> >> >> >> and >> >> >> >> >> so >> >> >> >> >> far >> >> >> >> >> I've never ran into any issues. But apparently it is not good >> >> >> >> >> -- >> >> >> >> >> why? >> >> >> >> >> >> >> >> >> >> a.2) #Array asClassInEnvironment: Smalltalk globals >> >> >> >> >> >> >> >> >> >> b) Retriving the class by key from the system dictionary >> >> >> >> >> >> >> >> >> >> b.1) Smalltalk globals at: #Array >> >> >> >> >> >> >> >> >> >> b.2) Smalltalk at: #Array >> >> >> >> >> >> >> >> >> >> b.3) Smalltalk classNamed: #Array >> >> >> >> >> >> >> >> >> >> c) something else entirely? >> >> >> >> >> >> >> >> >> >> I get that using #asClass wouldn't work if there was a >> >> >> >> >> different >> >> >> >> >> environment, however I don't even know in what situation there >> >> >> >> >> could >> >> >> >> >> be >> >> >> >> >> a >> >> >> >> >> different environment, so I cannot assert how problematic it >> >> >> >> >> is >> >> >> >> >> or >> >> >> >> >> isn't. >> >> >> >> >> >> >> >> >> >> Thanks, >> >> >> >> >> Peter >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > -- >> >> >> >> > ClÃ©ment BÃ©ra >> >> >> >> > Pharo consortium engineer >> >> >> >> > https://clementbera.wordpress.com/ >> >> >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq >> >> >> >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > ClÃ©ment BÃ©ra >> >> >> > Pharo consortium engineer >> >> >> > https://clementbera.wordpress.com/ >> >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq >> >> >> >> >> > >> >> >> > >> >

Feb. 11, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by Denis Kudriashov

2018-02-11 20:36 GMT+01:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > 2018-02-11 16:10 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > Hi Hernan. > > > > 2018-02-11 19:57 GMT+01:00 HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com>: > >> > >> Hi Denis > >> > >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> > > >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse <stepharo.self(a)gmail.com > >: > >> >> > >> >> Please to not use an unary on Symbol > >> >> Dispatch on something. > >> >> > >> >> self class environment at: #Array > >> >> is the best > >> > > >> > > >> > We should not use collection API for reflection calls. It makes them > >> > very > >> > difficult to find. Let's use explicit names like: > >> > > >> > >> Sorry I do not see it. > >> > >> The Collection API is beautiful, why couldn't be used for reflection? > > > > > > We have around 3000 senders of #at: message in the image. Do you think > it is > > easy to filter reflective calls? > > > > I still don't understand your use case, nor how the #at: is related > with the #asClass issue. > > Do you mean **further** filtering for relflective sends? > > Does this affects common-usage beyond Browser development? > The Stef proposal was that we should never use #asClass in the code. It is fine for scripting but not for the domain code by many reasons which were discussed here and at the past. But I only commented the proposed replacement: self class environment at: #Object If you do not like it, it is different story. I just described problem with #at: message: We already replaced many #asClass users with this code. And now it is quite difficult to find such places. They all hidden inside 3000 senders of #at:. If we will use #classNamed: instead of #at: then simple senders query will easily detect all reflective calls. (we probably already use it but not in all places). > > >> > >> I have no trouble finding #asClass senders, implementors, etc. > >> > >> What do you want to find? > >> > >> > self class environment classNamed: #Array > >> > > >> > >> Too much typing :) > >> > >> > > >> > From the other side we all agree that #asClass is super handy method. > >> > And we > >> > can fix it to respect sender environment using thisContext. It will > >> > affects > >> > performance but with our super powerful metalinks it can be easily > >> > cached > >> > (#asMethodConst is implemented that way). > >> > So we can make environment completely transparent for users. > >> > > >> > Best regards, > >> > Denis > >> > > >> >> > >> >> For Modules, we made progress and got bitten by many issues and > >> >> teaching > >> >> load. > >> >> > >> >> > >> >> Stef > >> >> > >> >> On Sat, Feb 10, 2018 at 4:50 PM, ClÃ©ment Bera < > bera.clement(a)gmail.com> > >> >> wrote: > >> >> > On Sat, Feb 10, 2018 at 4:34 PM, HernÃ¡n Morales Durand > >> >> > <hernan.morales(a)gmail.com> wrote: > >> >> >> > >> >> >> Hi ClÃ©ment, > >> >> >> > >> >> >> First time I read about modules in Pharo. > >> >> >> What is a module exactly? > >> >> >> > >> >> >> What's the problem to solve? > >> >> > > >> >> > > >> >> > It's similar to namespaces with some different, arguably better, > >> >> > features. > >> >> > > >> >> > Honestly I am not the expert on it so I would like some one else to > >> >> > answer. > >> >> > > >> >> > Among other things, it solves the problem of having 2 classes with > >> >> > the > >> >> > same > >> >> > name (avoiding the prefixes we have like in C). But reportedly > that's > >> >> > just a > >> >> > side-effect and not the main problem to solve. > >> >> > > >> >> >> > >> >> >> Cheers, > >> >> >> > >> >> >> HernÃ¡n > >> >> >> > >> >> >> 2018-02-10 9:47 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> >> >> > Hi, > >> >> >> > > >> >> >> > In short, everything that is not namespace/module compatible > will > >> >> >> > be > >> >> >> > deprecated/changed/removed in the future, so it is not > recommended > >> >> >> > to > >> >> >> > use > >> >> >> > it. > >> >> >> > > >> >> >> > a.2) #Array asClassInEnvironment: Smalltalk globals > >> >> >> > b.1) Smalltalk globals at: #Array > >> >> >> > => Ok-ish, note that you may need to change 'Smalltalk globals' > >> >> >> > the > >> >> >> > namespace/module when support for those will be added since > Array > >> >> >> > will > >> >> >> > be in > >> >> >> > a module. > >> >> >> > Maybe you want instead to use instead: > >> >> >> > > >> >> >> > c) self class environment at: #Array > >> >> >> > => this will work in the future if your code is a class which > >> >> >> > environment/namespace/module includes the Array class you would > >> >> >> > expect > >> >> >> > > >> >> >> > a.1) #Array asClass > >> >> >> > b.2) Smalltalk at: #Array > >> >> >> > b.3) Smalltalk classNamed: #Array > >> >> >> > => In which namespace/module are you looking for #Array ? In the > >> >> >> > future > >> >> >> > this > >> >> >> > may be removed, alternatively it will work only for globals but > >> >> >> > not > >> >> >> > globals > >> >> >> > inside namespace/module which won't work since Array will be in > a > >> >> >> > module. > >> >> >> > > >> >> >> > > >> >> >> > On Sat, Feb 10, 2018 at 12:57 PM, Peter UhnÃ¡k < > i.uhnak(a)gmail.com> > >> >> >> > wrote: > >> >> >> >> > >> >> >> >> Hi, > >> >> >> >> > >> >> >> >> what is the canonical way to get a class from a symbol? > >> >> >> >> > >> >> >> >> a) Converting symbol into class via string protocol > >> >> >> >> > >> >> >> >> a.1) #Array asClass > >> >> >> >> I use this the most, because it is easy, uses unary selector, > and > >> >> >> >> so > >> >> >> >> far > >> >> >> >> I've never ran into any issues. But apparently it is not good > -- > >> >> >> >> why? > >> >> >> >> > >> >> >> >> a.2) #Array asClassInEnvironment: Smalltalk globals > >> >> >> >> > >> >> >> >> b) Retriving the class by key from the system dictionary > >> >> >> >> > >> >> >> >> b.1) Smalltalk globals at: #Array > >> >> >> >> > >> >> >> >> b.2) Smalltalk at: #Array > >> >> >> >> > >> >> >> >> b.3) Smalltalk classNamed: #Array > >> >> >> >> > >> >> >> >> c) something else entirely? > >> >> >> >> > >> >> >> >> I get that using #asClass wouldn't work if there was a > different > >> >> >> >> environment, however I don't even know in what situation there > >> >> >> >> could > >> >> >> >> be > >> >> >> >> a > >> >> >> >> different environment, so I cannot assert how problematic it is > >> >> >> >> or > >> >> >> >> isn't. > >> >> >> >> > >> >> >> >> Thanks, > >> >> >> >> Peter > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > -- > >> >> >> > ClÃ©ment BÃ©ra > >> >> >> > Pharo consortium engineer > >> >> >> > https://clementbera.wordpress.com/ > >> >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > ClÃ©ment BÃ©ra > >> >> > Pharo consortium engineer > >> >> > https://clementbera.wordpress.com/ > >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > >> >> > >> > > >> > > > >

Feb. 11, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by HernÃ¡n Morales Durand

2018-02-11 16:10 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi Hernan. > > 2018-02-11 19:57 GMT+01:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: >> >> Hi Denis >> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> > >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> >> >> Please to not use an unary on Symbol >> >> Dispatch on something. >> >> >> >> self class environment at: #Array >> >> is the best >> > >> > >> > We should not use collection API for reflection calls. It makes them >> > very >> > difficult to find. Let's use explicit names like: >> > >> >> Sorry I do not see it. >> >> The Collection API is beautiful, why couldn't be used for reflection? > > > We have around 3000 senders of #at: message in the image. Do you think it is > easy to filter reflective calls? > I still don't understand your use case, nor how the #at: is related with the #asClass issue. Do you mean **further** filtering for relflective sends? Does this affects common-usage beyond Browser development? >> >> I have no trouble finding #asClass senders, implementors, etc. >> >> What do you want to find? >> >> > self class environment classNamed: #Array >> > >> >> Too much typing :) >> >> > >> > From the other side we all agree that #asClass is super handy method. >> > And we >> > can fix it to respect sender environment using thisContext. It will >> > affects >> > performance but with our super powerful metalinks it can be easily >> > cached >> > (#asMethodConst is implemented that way). >> > So we can make environment completely transparent for users. >> > >> > Best regards, >> > Denis >> > >> >> >> >> For Modules, we made progress and got bitten by many issues and >> >> teaching >> >> load. >> >> >> >> >> >> Stef >> >> >> >> On Sat, Feb 10, 2018 at 4:50 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >> >> wrote: >> >> > On Sat, Feb 10, 2018 at 4:34 PM, HernÃ¡n Morales Durand >> >> > <hernan.morales(a)gmail.com> wrote: >> >> >> >> >> >> Hi ClÃ©ment, >> >> >> >> >> >> First time I read about modules in Pharo. >> >> >> What is a module exactly? >> >> >> >> >> >> What's the problem to solve? >> >> > >> >> > >> >> > It's similar to namespaces with some different, arguably better, >> >> > features. >> >> > >> >> > Honestly I am not the expert on it so I would like some one else to >> >> > answer. >> >> > >> >> > Among other things, it solves the problem of having 2 classes with >> >> > the >> >> > same >> >> > name (avoiding the prefixes we have like in C). But reportedly that's >> >> > just a >> >> > side-effect and not the main problem to solve. >> >> > >> >> >> >> >> >> Cheers, >> >> >> >> >> >> HernÃ¡n >> >> >> >> >> >> 2018-02-10 9:47 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >> >> > Hi, >> >> >> > >> >> >> > In short, everything that is not namespace/module compatible will >> >> >> > be >> >> >> > deprecated/changed/removed in the future, so it is not recommended >> >> >> > to >> >> >> > use >> >> >> > it. >> >> >> > >> >> >> > a.2) #Array asClassInEnvironment: Smalltalk globals >> >> >> > b.1) Smalltalk globals at: #Array >> >> >> > => Ok-ish, note that you may need to change 'Smalltalk globals' >> >> >> > the >> >> >> > namespace/module when support for those will be added since Array >> >> >> > will >> >> >> > be in >> >> >> > a module. >> >> >> > Maybe you want instead to use instead: >> >> >> > >> >> >> > c) self class environment at: #Array >> >> >> > => this will work in the future if your code is a class which >> >> >> > environment/namespace/module includes the Array class you would >> >> >> > expect >> >> >> > >> >> >> > a.1) #Array asClass >> >> >> > b.2) Smalltalk at: #Array >> >> >> > b.3) Smalltalk classNamed: #Array >> >> >> > => In which namespace/module are you looking for #Array ? In the >> >> >> > future >> >> >> > this >> >> >> > may be removed, alternatively it will work only for globals but >> >> >> > not >> >> >> > globals >> >> >> > inside namespace/module which won't work since Array will be in a >> >> >> > module. >> >> >> > >> >> >> > >> >> >> > On Sat, Feb 10, 2018 at 12:57 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> >> >> >> > wrote: >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> what is the canonical way to get a class from a symbol? >> >> >> >> >> >> >> >> a) Converting symbol into class via string protocol >> >> >> >> >> >> >> >> a.1) #Array asClass >> >> >> >> I use this the most, because it is easy, uses unary selector, and >> >> >> >> so >> >> >> >> far >> >> >> >> I've never ran into any issues. But apparently it is not good -- >> >> >> >> why? >> >> >> >> >> >> >> >> a.2) #Array asClassInEnvironment: Smalltalk globals >> >> >> >> >> >> >> >> b) Retriving the class by key from the system dictionary >> >> >> >> >> >> >> >> b.1) Smalltalk globals at: #Array >> >> >> >> >> >> >> >> b.2) Smalltalk at: #Array >> >> >> >> >> >> >> >> b.3) Smalltalk classNamed: #Array >> >> >> >> >> >> >> >> c) something else entirely? >> >> >> >> >> >> >> >> I get that using #asClass wouldn't work if there was a different >> >> >> >> environment, however I don't even know in what situation there >> >> >> >> could >> >> >> >> be >> >> >> >> a >> >> >> >> different environment, so I cannot assert how problematic it is >> >> >> >> or >> >> >> >> isn't. >> >> >> >> >> >> >> >> Thanks, >> >> >> >> Peter >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > ClÃ©ment BÃ©ra >> >> >> > Pharo consortium engineer >> >> >> > https://clementbera.wordpress.com/ >> >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > ClÃ©ment BÃ©ra >> >> > Pharo consortium engineer >> >> > https://clementbera.wordpress.com/ >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq >> >> >> > >> >

Feb. 11, 2018

Re: [Pharo-users] Object configuration idioms

by Christian Caldeiro

Maybe using directly TwitterClient, but using #doesNotUnderstand: to delegate there message sends to the configuration object(kind of a proxy pattern). That way the TwitterClient class doesn't became so heavy. Christian On Sun, Feb 11, 2018 at 1:35 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Why not directly on TwitterClient ? That would be easiest for the user, > then they do not need to know about TwitterConfiguration. Anyway, that is > how I do it most often. The disadvantage is that TwitterClient might become > a bit heavy, API wise, but you can delegate internally. > > > On 11 Feb 2018, at 16:25, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > are there any best practices/idioms in regards to object > configuration/building? > > > > Let's say I want to configure a TwitterClient that requires a username > and a password that is stored in a separate object TwitterConfiguration > > > > a) the basic approach (either separate sends or via cascade, that is not > relevant here) > > > > client := TwitterClient new. > > client configuration username: 'XX'. > > client configuration password: 'YY'. > > > > > > b) #in: ... > > > > It feels a bit more organized as it basically groups related operations > together. > > Also maybe avoiding demeter a bit? > > > > client := TwitterClient new. > > client configuration in: [ :config | > > config username: 'XX'. > > config password: 'YY'. > > ]. > > > > c) custom #somethingDo: method that basically does #in: > > > > Again, feels more organized. Additionally one could perform some > validation afterwards (to make sure the credentials are ok or whatever). > > > > client := TwitterClient new. > > client configurationDo: [ :config | > > config username: 'XX'. > > config password: 'YY' > > ]. > > > > Any thoughts on this? > > > > Thanks, > > Peter > > >

Feb. 11, 2018