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" <steph...@free.fr
<mailto:steph...@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
