Hi,

There exists already a method for that:
        Symbol>>asClassInEnvironment:

But, what if we introduce:

Symbol>>asClassFrom: anObject
        ^ self asClassInEnvironment: anObject 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).

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


Reply via email to