Thanks doru.
I do not like when people think that we are complaining just because
something changes.
It should change for the better and we all agree on that.
Stef
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.
Yes, but asClassFrom: would not be unary but would save us from typing an extra
"class environment" :).
Yes I see.
But inside Pharo core tools we are ready to type
environment as a message that dispatch to something else than a symbol.
Sure.
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.
:D
Yes, yes. I just talked with Guille. Moving these scripting methods outside of
the Kernel is clearly a must.
I think that each time you use them we will preempt cross compilation and
others.
Yes, we agree that this method should not be used inside code.
I was just thinking that we can make it so that we do not break any code while
still making it dynamic.
I do not like your definition of dynamic. Sending a message to an object is
dynamic.
What you imply is compact. I can understand it when typing in playground.
By dynamic I meant the dispatch through “self class environment” or “self
environment” which is what people will use by default.
Like with scripting solutions there is a performance penalty, but that is fine if
people choose to pay it (like in the case of Symbol>>#value:).
Yes for scripts. Not for core code.
Since people tend to be a bit lazy I think that having rules will make sense.
Definitely.
Doru
Cheers,
Doru
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."
--
www.tudorgirba.com
www.feenk.com
"Quality cannot be an afterthought."
--
www.tudorgirba.com
www.feenk.com
"Every thing has its own flow."
