2018-02-11 16:55 GMT-03:00 Denis Kudriashov <dionisi...@gmail.com>: > > > 2018-02-11 20:36 GMT+01:00 Hernán Morales Durand <hernan.mora...@gmail.com>: >> >> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov <dionisi...@gmail.com>: >> > Hi Hernan. >> > >> > 2018-02-11 19:57 GMT+01:00 Hernán Morales Durand >> > <hernan.mora...@gmail.com>: >> >> >> >> Hi Denis >> >> >> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <dionisi...@gmail.com>: >> >> > >> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse >> >> > <stepharo.s...@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.clem...@gmail.com> >> >> >> wrote: >> >> >> > On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand >> >> >> > <hernan.mora...@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.clem...@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.uh...@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 >> >> >> >> >> > >> >> >> > >> >
