February 2018 - Pharo-users

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

by Richard Sargent

There are two use cases that come immediately to mind. They may be the two most important. "As a Compiler, I need to be able to resolve a Symbol to a known Object." "As a Browser, I need to be able to identify the possible resolutions of a String to known Objects." I can elaborate on those, but I think they are pretty clear no matter what scopes, namespaces, environments, modules, or whatever one uses to organize things in the image. (One can even imagine an external registry of names that could be searched and yield up suggestions of external packages that would be needed.) On Sun, Feb 11, 2018 at 12:42 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 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 >> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d'Ascq&entry=gmail&source=g> >> 'Ascq >> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d'Ascq&entry=gmail&source=g> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > -- >> >> >> >> > ClÃ©ment BÃ©ra >> >> >> >> > Pharo consortium engineer >> >> >> >> > https://clementbera.wordpress.com/ >> >> >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d >> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d'Ascq&entry=gmail&source=g> >> 'Ascq >> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d'Ascq&entry=gmail&source=g> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> > >> >> >

Feb. 11, 2018

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