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