Hi, > On Aug 25, 2016, at 10:10 PM, 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" :). > Yes I see. > But inside Pharo core tools we are ready to type > environment as a message that dispatch to something else than a symbol.
Sure. >>>> 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 think that each time you use them we will preempt cross compilation and > others. Yes, we agree that this method should not be used inside code. >>> I was just thinking that we can make it so that we do not break any code >>> while still making it dynamic. > I do not like your definition of dynamic. Sending a message to an object is > dynamic. > What you imply is compact. I can understand it when typing in playground. By dynamic I meant the dispatch through “self class environment” or “self environment” which is what people will use by default. >>> 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:). > Yes for scripts. Not for core code. > Since people tend to be a bit lazy I think that having rules will make sense. Definitely. Doru >>> >>> 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." -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."
