Hi, > On Aug 25, 2016, at 9:52 AM, stepharo <steph...@free.fr> wrote: > > >> Hi, >> >> There exists already a method for that: >> Symbol>>asClassInEnvironment: >> >> But, what if we introduce: >> >> Symbol>>asClassFrom: anObject >> ^ self asClassInEnvironment: anObject class environment >> >> ? > The problem is asClass unary. > > All the tools should be parametrized by an environment.
Yes, but asClassFrom: would not be unary but would save us from typing an extra "class environment" :). >> This would allow us to still script and be dynamic. >> >> Furthermore, as #asClass is meant to be mainly used for convenience, not >> performance, I would also propose to make it lookup in thisContext and take >> the environment from there. I know that his might sound like magic, but it >> would be the default that we are looking for (to always lookup through the >> current environment dynamically). > > argh I will die....:) > No use of thisContext or only in the scripting package. :D Yes, yes. I just talked with Guille. Moving these scripting methods outside of the Kernel is clearly a must. I was just thinking that we can make it so that we do not break any code while still making it dynamic. Like with scripting solutions there is a performance penalty, but that is fine if people choose to pay it (like in the case of Symbol>>#value:). Cheers, Doru >> >> What do you think? >> >> Cheers, >> Doru >> >> >> >>> On Aug 25, 2016, at 8:34 AM, Yuriy Tymchuk <yuriy.tymc...@me.com> wrote: >>> >>> Just my 2 cents: >>> >>> >>> instead of >>> >>> #name asClass >>> >>> we have to use >>> >>> self class environment at: #name. >>> >>> >>> Maybe instead of #at: we can have #classNamed:? Or something similar? >>> Because 1) it’s not obvious that the method will give you a class, what if >>> in the future and environment can also have a mapping of something else >>> like packages? >>> >>> Uko >>> >>>> On 25 Aug 2016, at 07:21, stepharo <steph...@free.fr> wrote: >>>> >>>> Hi guys >>>> >>>> We got a meeting at ESUG with all the compiler guys and james from >>>> gemstone. >>>> >>>> Our goal is to have a full tool suite that can be parametrized by >>>> environments (so that >>>> >>>> we can compile code in other space, or compile other code inside pharo). >>>> >>>> I personnally started this effort one decade ago. Now the introduction >>>> >>>> of #asClass and friend is simply destroying all our efforts. There was a >>>> discussion >>>> >>>> in the past but we are not listened. >>>> >>>> We will >>>> >>>> - packaged these extensions in a separate package >>>> >>>> - add rules to ban the use of such method in Pharo >>>> >>>> - fix all the use (again) to use the correct way to do it. >>>> >>>> >>>> I can understand that for scripting this is easier but it cannot be at >>>> that cost and impact. >>>> >>>> I hope that we will understand but we have to do something else than >>>> >>>> fixing code that breaks our effort. >>>> >>>> >>>> Stef, Marcus, Guille and Luc >>>> >>>> >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "It's not what we do that matters most, it's how we do it." >> >> >> > > -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."
