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

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