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.tymchuk@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 <stepharo@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."