Ah, I am using that a lot to parametrize software.

On one hand Pharo is breaking with the past, on the other one it sticks with it as much as possible? #MeConfused asHell.

This has nothing to do with complying with the past.
Do you think seriously that if we could replace self class env: #foo but #foo asClass and get the same
we would not do it?
Since you know that we are smart guys, I let you as an exercise to understand why we are picky about not using it.

#SomeSymbol asClass looks very practical and cleaner that looking the class dictionary with at: #SomeSymbol

No but I will let you try to find a bit by yourself before telling it to you why ;D

Some hints: if you do not want that we succeed to
������ ������ - be able to compile pharo code inside a different namespace, object space,
������ ������ - be able to compile the compiler code modified to be able to recompile itself
������ ������ - be able to use our tools to compile code for another system like Gemstone
then yes let us use a solution with 7 letters less because it is not cleaner but shorter.

Stef

Phil

Phil


Le��25 ao��t 2016 07:22, "stepharo" <stepharo@free.fr> a ��crit��:
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