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
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
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."
Le 25 août 2016 08:53, "Tudor Girba" <tudor@tudorgirba.com> a écrit :
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?
Great. Makes sense. Can always monkey patch my way anyway. "Pharo is yours" someone said. But I am not feeling the pain of getting things running in Gemstone from wild Pharo so, ... Phil
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."
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.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."
Hi,
On Aug 25, 2016, at 9:52 AM, stepharo <stepharo@free.fr> wrote:
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" :).
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 was just thinking that we can make it so that we do not break any code while still making it dynamic. 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:). Cheers, Doru
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."
-- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."
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.
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.
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. 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.
Cheers, Doru
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."
-- www.tudorgirba.com www.feenk.com
"Quality cannot be an afterthought."
Hi,
On Aug 25, 2016, at 10:10 PM, stepharo <stepharo@free.fr> wrote:
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.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."
-- www.tudorgirba.com www.feenk.com
"Quality cannot be an afterthought."
-- www.tudorgirba.com www.feenk.com "Every thing has its own flow."
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.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."
-- www.tudorgirba.com www.feenk.com
"Quality cannot be an afterthought." -- www.tudorgirba.com www.feenk.com
"Every thing has its own flow."
Hi,
On Aug 26, 2016, at 6:37 AM, stepharo <stepharo@free.fr> wrote:
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.
Certainly. There are many points of view and many constraints. This is why it is so important that we all bring forward those constraints because only like this we can reach a global maximum. So, about asClass, everyone agrees that it should be moved to another package. The open questions are: - do we add an automatic deprecation for those that use it in code, or - do we make use of thisContext to retrieve the environment? (or both) Also, what about the asClassInEnvironment: method? Can it be used in code, or do we better discourage its usage altogether? I am thinking that if we have to write: #MyClass asClassInEnvironment: self class environment is even longer than: self environment at: #MyClass so, I think there is little point to it. In fact, for scripting what I find useful is not so much less characters, but the lack of parentheses, hence unary methods. That is why asClass is worth being salvaged for scripting (even with a solution that is slower with thisContext), but the rest maybe can be removed. What do you think? Cheers, Doru
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.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."
-- www.tudorgirba.com www.feenk.com
"Quality cannot be an afterthought." -- www.tudorgirba.com www.feenk.com
"Every thing has its own flow."
-- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different."
Hi, My point of view is: 1) in code/core, we should use (we already said that with Camille in the past ;-)): self environmentAt: #Blah Object>>environmentAt: aSymbol ^ self class environmentAt: aSymbol Object class>>environmentAt: aSymbol ... The idea is that we can then customize name resolution, per object, per class and per module in the future. 2) For scripting purpose, asClass is indeed useful (GTInspector, ...). I would start simple as said before, re-package it and add a rule as suggested by Denis. Now, I am not sure that making asClass supporting name resolution in another environment is really useful. And if we do it using thisContext, some developers may use that instead of "obj environmentAt: XXX" which would be bad. my 2KÄ, #Luc 2016-08-26 6:56 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Aug 26, 2016, at 6:37 AM, stepharo <stepharo@free.fr> wrote:
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.
Certainly. There are many points of view and many constraints. This is why it is so important that we all bring forward those constraints because only like this we can reach a global maximum.
So, about asClass, everyone agrees that it should be moved to another package. The open questions are: - do we add an automatic deprecation for those that use it in code, or - do we make use of thisContext to retrieve the environment? (or both)
Also, what about the asClassInEnvironment: method? Can it be used in code, or do we better discourage its usage altogether? I am thinking that if we have to write: #MyClass asClassInEnvironment: self class environment is even longer than: self environment at: #MyClass so, I think there is little point to it.
In fact, for scripting what I find useful is not so much less characters, but the lack of parentheses, hence unary methods. That is why asClass is worth being salvaged for scripting (even with a solution that is slower with thisContext), but the rest maybe can be removed. What do you think?
Cheers, Doru
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.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."
-- www.tudorgirba.com www.feenk.com
"Quality cannot be an afterthought." -- www.tudorgirba.com www.feenk.com
"Every thing has its own flow."
-- www.tudorgirba.com www.feenk.com
"Every thing should have the right to be different."
On 26 Aug 2016, at 08:49, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi,
My point of view is:
1) in code/core, we should use (we already said that with Camille in the past ;-)):
self environmentAt: #Blah
Object>>environmentAt: aSymbol ^ self class environmentAt: aSymbol
Object class>>environmentAt: aSymbol ...
The idea is that we can then customize name resolution, per object, per class and per module in the future.
+1
2) For scripting purpose, asClass is indeed useful (GTInspector, ...). I would start simple as said before, re-package it and add a rule as suggested by Denis. Now, I am not sure that making asClass supporting name resolution in another environment is really useful. And if we do it using thisContext, some developers may use that instead of "obj environmentAt: XXX" which would be bad.
I dislike a lot the thisContext resolution idea. If is bad is bad⦠and it will be bad also for scripting. I know, now it does not looks like adding value, but think about: #asClass is monolithic and #asClass with thisContext âlooks monolithicâ, IMO promoting a bad way of thinking problems in Pharo thus inducing confusion for non expert users. Esteban
my 2KÄ,
#Luc
2016-08-26 6:56 GMT+02:00 Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>>: Hi,
On Aug 26, 2016, at 6:37 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
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.
Certainly. There are many points of view and many constraints. This is why it is so important that we all bring forward those constraints because only like this we can reach a global maximum.
So, about asClass, everyone agrees that it should be moved to another package. The open questions are: - do we add an automatic deprecation for those that use it in code, or - do we make use of thisContext to retrieve the environment? (or both)
Also, what about the asClassInEnvironment: method? Can it be used in code, or do we better discourage its usage altogether? I am thinking that if we have to write: #MyClass asClassInEnvironment: self class environment is even longer than: self environment at: #MyClass so, I think there is little point to it.
In fact, for scripting what I find useful is not so much less characters, but the lack of parentheses, hence unary methods. That is why asClass is worth being salvaged for scripting (even with a solution that is slower with thisContext), but the rest maybe can be removed. What do you think?
Cheers, Doru
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.tymchuk@me.com <mailto: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 <mailto: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 <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/>
"It's not what we do that matters most, it's how we do it."
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/>
"Quality cannot be an afterthought." -- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/>
"Every thing has its own flow."
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/>
"Every thing should have the right to be different."
2016-08-26 9:10 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 26 Aug 2016, at 08:49, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi,
My point of view is:
1) in code/core, we should use (we already said that with Camille in the past ;-)):
self environmentAt: #Blah
Object>>environmentAt: aSymbol ^ self class environmentAt: aSymbol
Object class>>environmentAt: aSymbol ...
The idea is that we can then customize name resolution, per object, per class and per module in the future.
+1
2) For scripting purpose, asClass is indeed useful (GTInspector, ...). I would start simple as said before, re-package it and add a rule as suggested by Denis. Now, I am not sure that making asClass supporting name resolution in another environment is really useful. And if we do it using thisContext, some developers may use that instead of "obj environmentAt: XXX" which would be bad.
I dislike a lot the thisContext resolution idea. If is bad is bad⦠and it will be bad also for scripting. I know, now it does not looks like adding value, but think about: #asClass is monolithic and #asClass with thisContext âlooks monolithicâ, IMO promoting a bad way of thinking problems in Pharo thus inducing confusion for non expert users.
this is my feeling too. Luc
Esteban
my 2KÄ,
#Luc
2016-08-26 6:56 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Aug 26, 2016, at 6:37 AM, stepharo <stepharo@free.fr> wrote:
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.
Certainly. There are many points of view and many constraints. This is why it is so important that we all bring forward those constraints because only like this we can reach a global maximum.
So, about asClass, everyone agrees that it should be moved to another package. The open questions are: - do we add an automatic deprecation for those that use it in code, or - do we make use of thisContext to retrieve the environment? (or both)
Also, what about the asClassInEnvironment: method? Can it be used in code, or do we better discourage its usage altogether? I am thinking that if we have to write: #MyClass asClassInEnvironment: self class environment is even longer than: self environment at: #MyClass so, I think there is little point to it.
In fact, for scripting what I find useful is not so much less characters, but the lack of parentheses, hence unary methods. That is why asClass is worth being salvaged for scripting (even with a solution that is slower with thisContext), but the rest maybe can be removed. What do you think?
Cheers, Doru
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.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."
-- www.tudorgirba.com www.feenk.com
"Quality cannot be an afterthought." -- www.tudorgirba.com www.feenk.com
"Every thing has its own flow."
-- www.tudorgirba.com www.feenk.com
"Every thing should have the right to be different."
Hi,
On Aug 26, 2016, at 9:10 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 26 Aug 2016, at 08:49, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi,
My point of view is:
1) in code/core, we should use (we already said that with Camille in the past ;-)):
self environmentAt: #Blah
Object>>environmentAt: aSymbol ^ self class environmentAt: aSymbol
Object class>>environmentAt: aSymbol ...
The idea is that we can then customize name resolution, per object, per class and per module in the future.
+1
2) For scripting purpose, asClass is indeed useful (GTInspector, ...). I would start simple as said before, re-package it and add a rule as suggested by Denis. Now, I am not sure that making asClass supporting name resolution in another environment is really useful. And if we do it using thisContext, some developers may use that instead of "obj environmentAt: XXX" which would be bad.
I dislike a lot the thisContext resolution idea. If is bad is bad⦠and it will be bad also for scripting. I know, now it does not looks like adding value, but think about: #asClass is monolithic and #asClass with thisContext âlooks monolithicâ, IMO promoting a bad way of thinking problems in Pharo thus inducing confusion for non expert users.
No problem from my side. It was a proposal. I wanted to learn a bit and I was looking for concrete arguments to learn from because I am likely missing something. I still do not know why it is bad, but it is really not important for the current issue. So, we agree that: - move asClass together with all other in a separate package. - introduce deprecation. I created an issue: https://pharo.fogbugz.com/f/cases/18987/Extract-asClass-and-friends-in-a-sep... Doru
Esteban
my 2KÄ,
#Luc
2016-08-26 6:56 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 26, 2016, at 6:37 AM, stepharo <stepharo@free.fr> wrote:
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.
Certainly. There are many points of view and many constraints. This is why it is so important that we all bring forward those constraints because only like this we can reach a global maximum.
So, about asClass, everyone agrees that it should be moved to another package. The open questions are: - do we add an automatic deprecation for those that use it in code, or - do we make use of thisContext to retrieve the environment? (or both)
Also, what about the asClassInEnvironment: method? Can it be used in code, or do we better discourage its usage altogether? I am thinking that if we have to write: #MyClass asClassInEnvironment: self class environment is even longer than: self environment at: #MyClass so, I think there is little point to it.
In fact, for scripting what I find useful is not so much less characters, but the lack of parentheses, hence unary methods. That is why asClass is worth being salvaged for scripting (even with a solution that is slower with thisContext), but the rest maybe can be removed. What do you think?
Cheers, Doru
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.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."
-- www.tudorgirba.com www.feenk.com
"Quality cannot be an afterthought." -- www.tudorgirba.com www.feenk.com
"Every thing has its own flow."
-- www.tudorgirba.com www.feenk.com
"Every thing should have the right to be different."
-- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."
Hi! 1) I think we are failing also at communicating one point better. It is not that people is arguing against #asClass because it's ugly and bad and a terrible villain. Ok, maybe a bit, but also: The point is that #asClass, as it looks handy and easy to use, it may not work in the future. Why? Because if you imaging a Pharo with modules, explicit imports, and even namespaces, then you may have several classes with the same name. And then you may have name clashes. And #asClass will not have a single obvious result. And that makes #asClass both impractical and with no sense at the same time. One other reality: - We are thinking about a problem we do not yet have... :) 2) Then, I agree with Doru, with Luc and with (E)(Ste(f|ban)). But I also agree with Phil and myself. And my position says: - Let the kernel be clean. There should not be an #asClass or similar implementation as part of the kernel. This extension should exist not as part of the kernel but as part of other package (I'd vote for ScriptingExtensions for example). - Let the kernel be clean (bis). We should not have users of such *scripting nicety* inside the kernel. We should put in place a lint rule to validate that. - But we should let people use #asClass if they want in their code! And thus we should not deprecate it. We should not control what Phil does to get business. I agree that Pharo itself should not use #asClass, but also that (a good implementation of) #asClass or similar should be available for him. At the end, there will be so many packages and libraries out there that we have to realize we can only guarantee that Pharo gives you an empowering environment and people will use it and do whatever they want :). I updated the issue with some of these ideas https://pharo.fogbugz.com/f/cases/18987/Extract-asClass-and-friends-in-a-sep... Guille -------- Original Message --------
Hi,
On Aug 26, 2016, at 9:10 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 26 Aug 2016, at 08:49, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi,
My point of view is:
1) in code/core, we should use (we already said that with Camille in the past ;-)):
self environmentAt: #Blah
Object>>environmentAt: aSymbol ^ self class environmentAt: aSymbol
Object class>>environmentAt: aSymbol ...
The idea is that we can then customize name resolution, per object, per class and per module in the future. +1
2) For scripting purpose, asClass is indeed useful (GTInspector, ...). I would start simple as said before, re-package it and add a rule as suggested by Denis. Now, I am not sure that making asClass supporting name resolution in another environment is really useful. And if we do it using thisContext, some developers may use that instead of "obj environmentAt: XXX" which would be bad. I dislike a lot the thisContext resolution idea. If is bad is bad⦠and it will be bad also for scripting. I know, now it does not looks like adding value, but think about: #asClass is monolithic and #asClass with thisContext âlooks monolithicâ, IMO promoting a bad way of thinking problems in Pharo thus inducing confusion for non expert users. No problem from my side. It was a proposal. I wanted to learn a bit and I was looking for concrete arguments to learn from because I am likely missing something. I still do not know why it is bad, but it is really not important for the current issue.
So, we agree that: - move asClass together with all other in a separate package. - introduce deprecation.
I created an issue: https://pharo.fogbugz.com/f/cases/18987/Extract-asClass-and-friends-in-a-sep...
Doru
Esteban
my 2KÄ,
#Luc
2016-08-26 6:56 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 26, 2016, at 6:37 AM, stepharo <stepharo@free.fr> wrote:
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. Certainly. There are many points of view and many constraints. This is why it is so important that we all bring forward those constraints because only like this we can reach a global maximum.
So, about asClass, everyone agrees that it should be moved to another package. The open questions are: - do we add an automatic deprecation for those that use it in code, or - do we make use of thisContext to retrieve the environment? (or both)
Also, what about the asClassInEnvironment: method? Can it be used in code, or do we better discourage its usage altogether? I am thinking that if we have to write: #MyClass asClassInEnvironment: self class environment is even longer than: self environment at: #MyClass so, I think there is little point to it.
In fact, for scripting what I find useful is not so much less characters, but the lack of parentheses, hence unary methods. That is why asClass is worth being salvaged for scripting (even with a solution that is slower with thisContext), but the rest maybe can be removed. What do you think?
Cheers, Doru
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.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."
-- www.tudorgirba.com www.feenk.com
"Quality cannot be an afterthought." -- www.tudorgirba.com www.feenk.com
"Every thing has its own flow."
-- www.tudorgirba.com www.feenk.com
"Every thing should have the right to be different." -- www.tudorgirba.com www.feenk.com
"Be rather willing to give than demanding to get."
On Fri, Aug 26, 2016 at 10:07 AM, Guille Polito <guillermopolito@gmail.com> wrote:
Hi!
1) I think we are failing also at communicating one point better. It is not that people is arguing against #asClass because it's ugly and bad and a terrible villain. Ok, maybe a bit, but also:
The point is that #asClass, as it looks handy and easy to use, it may not work in the future.
Why?
Because if you imaging a Pharo with modules, explicit imports, and even namespaces, then you may have several classes with the same name. And then you may have name clashes. And #asClass will not have a single obvious result. And that makes #asClass both impractical and with no sense at the same time.
One other reality:
- We are thinking about a problem we do not yet have... :)
2) Then, I agree with Doru, with Luc and with (E)(Ste(f|ban)). But I also agree with Phil and myself. And my position says:
- Let the kernel be clean. There should not be an #asClass or similar implementation as part of the kernel. This extension should exist not as part of the kernel but as part of other package (I'd vote for ScriptingExtensions for example).
- Let the kernel be clean (bis). We should not have users of such *scripting nicety* inside the kernel. We should put in place a lint rule to validate that.
100% agreeing with that. I understand that concern. Not a stranger to Java ClassLoading madness in JEE, well, yeah.
- But we should let people use #asClass if they want in their code! And thus we should not deprecate it. We should not control what Phil does to get business. I agree that Pharo itself should not use #asClass, but also that (a good implementation of) #asClass or similar should be available for him. At the end, there will be so many packages and libraries out there that we have to realize we can only guarantee that Pharo gives you an empowering environment and people will use it and do whatever they want :).
One reason I like Pharo is also that I can work *without* all of that package annoying concern in my user level code. Just one flat namespace, easy to deal with. VisualWorks does something like that with a default namespace as it seems. Now, namespaced packages are good, but only if one needs them. Comparing the Pharo with the Java codebases I've got here, well, navigating Pharo is much easier and one can really grok a good amount of stuff. The kernel and user space separation has been somewhat there for ages. Unix anyone? I don't care about how the kernel is done as long as I have my API available and I can load the .so I need.
I updated the issue with some of these ideas
https://pharo.fogbugz.com/f/cases/18987/Extract-asClass-and- friends-in-a-separate-package-and-deprecate
Guille
-------- Original Message --------
Hi,
On Aug 26, 2016, at 9:10 AM, Esteban Lorenzano <estebanlm@gmail.com>
wrote:
On 26 Aug 2016, at 08:49, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi,
My point of view is:
1) in code/core, we should use (we already said that with Camille in the past ;-)):
self environmentAt: #Blah
Object>>environmentAt: aSymbol ^ self class environmentAt: aSymbol
Object class>>environmentAt: aSymbol ...
The idea is that we can then customize name resolution, per object, per class and per module in the future.
+1
2) For scripting purpose, asClass is indeed useful (GTInspector, ...).
I would start simple as said before, re-package it and add a rule as suggested by Denis. Now, I am not sure that making asClass supporting name resolution in another environment is really useful. And if we do it using thisContext, some developers may use that instead of "obj environmentAt: XXX" which would be bad.
I dislike a lot the thisContext resolution idea. If is bad is bad⦠and it will be bad also for scripting. I know, now it does not looks like adding value, but think about: #asClass is monolithic and #asClass with thisContext âlooks monolithicâ, IMO promoting a bad way of thinking problems in Pharo thus inducing confusion for non expert users.
No problem from my side. It was a proposal. I wanted to learn a bit and I was looking for concrete arguments to learn from because I am likely missing something. I still do not know why it is bad, but it is really not important for the current issue.
So, we agree that: - move asClass together with all other in a separate package. - introduce deprecation.
I created an issue: https://pharo.fogbugz.com/f/cases/18987/Extract-asClass-and- friends-in-a-separate-package-and-deprecate
Doru
Esteban
my 2KÄ,
#Luc
2016-08-26 6:56 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 26, 2016, at 6:37 AM, stepharo <stepharo@free.fr> wrote:
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.
Certainly. There are many points of view and many constraints. This is why it is so important that we all bring forward those constraints because only like this we can reach a global maximum.
So, about asClass, everyone agrees that it should be moved to another package. The open questions are: - do we add an automatic deprecation for those that use it in code, or - do we make use of thisContext to retrieve the environment? (or both)
Also, what about the asClassInEnvironment: method? Can it be used in code, or do we better discourage its usage altogether? I am thinking that if we have to write: #MyClass asClassInEnvironment: self class environment is even longer than: self environment at: #MyClass so, I think there is little point to it.
In fact, for scripting what I find useful is not so much less characters, but the lack of parentheses, hence unary methods. That is why asClass is worth being salvaged for scripting (even with a solution that is slower with thisContext), but the rest maybe can be removed. What do you think?
Cheers, Doru
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.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."
--
www.tudorgirba.com www.feenk.com
"Quality cannot be an afterthought."
-- www.tudorgirba.com www.feenk.com
"Every thing has its own flow."
--
www.tudorgirba.com www.feenk.com
"Every thing should have the right to be different."
--
www.tudorgirba.com www.feenk.com
"Be rather willing to give than demanding to get."
Here is an example where asClass is useful. Someone posts something in the mail list like this... Gofer it smalltalkhubUser: 'hernan' project: 'CodeGenerator'; configuration; loadDevelopment. CGSmalltalkExamples exampleNSISPharo4. and pure laziness (apparently a sign of a good programmer??[1]), I'd like to be able to select from the web page, paste and evaluate the whole thing in one go, but CGSmalltalkExamples is unknown and cannot compile. But for my personal use, that is my only example. I wonder if the following proposal may be a reasonable alternative approach to put on a project's documentation page... Gofer it smalltalkhubUser: 'hernan' project: 'CodeGenerator'; configuration; loadDevelopment; eval:'CGSmalltalkExamples exampleNSISPharo4'. [1] https://www.techwell.com/techwell-insights/2013/12/why-best-programmers-are-... cheers -ben On Fri, Aug 26, 2016 at 4:40 PM, phil@highoctane.be <phil@highoctane.be> wrote:
On Fri, Aug 26, 2016 at 10:07 AM, Guille Polito <guillermopolito@gmail.com> wrote:
Hi!
1) I think we are failing also at communicating one point better. It is not that people is arguing against #asClass because it's ugly and bad and a terrible villain. Ok, maybe a bit, but also:
The point is that #asClass, as it looks handy and easy to use, it may not work in the future.
Why?
Because if you imaging a Pharo with modules, explicit imports, and even namespaces, then you may have several classes with the same name. And then you may have name clashes. And #asClass will not have a single obvious result. And that makes #asClass both impractical and with no sense at the same time.
One other reality:
- We are thinking about a problem we do not yet have... :)
2) Then, I agree with Doru, with Luc and with (E)(Ste(f|ban)). But I also agree with Phil and myself. And my position says:
- Let the kernel be clean. There should not be an #asClass or similar implementation as part of the kernel. This extension should exist not as part of the kernel but as part of other package (I'd vote for ScriptingExtensions for example).
- Let the kernel be clean (bis). We should not have users of such *scripting nicety* inside the kernel. We should put in place a lint rule to validate that.
100% agreeing with that. I understand that concern. Not a stranger to Java ClassLoading madness in JEE, well, yeah.
- But we should let people use #asClass if they want in their code! And thus we should not deprecate it. We should not control what Phil does to get business. I agree that Pharo itself should not use #asClass, but also that (a good implementation of) #asClass or similar should be available for him. At the end, there will be so many packages and libraries out there that we have to realize we can only guarantee that Pharo gives you an empowering environment and people will use it and do whatever they want :).
One reason I like Pharo is also that I can work *without* all of that package annoying concern in my user level code. Just one flat namespace, easy to deal with. VisualWorks does something like that with a default namespace as it seems. Now, namespaced packages are good, but only if one needs them.
Comparing the Pharo with the Java codebases I've got here, well, navigating Pharo is much easier and one can really grok a good amount of stuff.
The kernel and user space separation has been somewhat there for ages. Unix anyone? I don't care about how the kernel is done as long as I have my API available and I can load the .so I need.
I updated the issue with some of these ideas
https://pharo.fogbugz.com/f/cases/18987/Extract-asClass-and-friends-in-a-sep...
Guille
-------- Original Message --------
Hi,
On Aug 26, 2016, at 9:10 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 26 Aug 2016, at 08:49, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi,
My point of view is:
1) in code/core, we should use (we already said that with Camille in the past ;-)):
self environmentAt: #Blah
Object>>environmentAt: aSymbol ^ self class environmentAt: aSymbol
Object class>>environmentAt: aSymbol ...
The idea is that we can then customize name resolution, per object, per class and per module in the future.
+1
2) For scripting purpose, asClass is indeed useful (GTInspector, ...). I would start simple as said before, re-package it and add a rule as suggested by Denis. Now, I am not sure that making asClass supporting name resolution in another environment is really useful. And if we do it using thisContext, some developers may use that instead of "obj environmentAt: XXX" which would be bad.
I dislike a lot the thisContext resolution idea. If is bad is bad⦠and it will be bad also for scripting. I know, now it does not looks like adding value, but think about: #asClass is monolithic and #asClass with thisContext âlooks monolithicâ, IMO promoting a bad way of thinking problems in Pharo thus inducing confusion for non expert users.
No problem from my side. It was a proposal. I wanted to learn a bit and I was looking for concrete arguments to learn from because I am likely missing something. I still do not know why it is bad, but it is really not important for the current issue.
So, we agree that: - move asClass together with all other in a separate package. - introduce deprecation.
I created an issue:
https://pharo.fogbugz.com/f/cases/18987/Extract-asClass-and-friends-in-a-sep...
Doru
Esteban
my 2KÄ,
#Luc
2016-08-26 6:56 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 26, 2016, at 6:37 AM, stepharo <stepharo@free.fr> wrote:
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.
Certainly. There are many points of view and many constraints. This is why it is so important that we all bring forward those constraints because only like this we can reach a global maximum.
So, about asClass, everyone agrees that it should be moved to another package. The open questions are: - do we add an automatic deprecation for those that use it in code, or - do we make use of thisContext to retrieve the environment? (or both)
Also, what about the asClassInEnvironment: method? Can it be used in code, or do we better discourage its usage altogether? I am thinking that if we have to write: #MyClass asClassInEnvironment: self class environment is even longer than: self environment at: #MyClass so, I think there is little point to it.
In fact, for scripting what I find useful is not so much less characters, but the lack of parentheses, hence unary methods. That is why asClass is worth being salvaged for scripting (even with a solution that is slower with thisContext), but the rest maybe can be removed. What do you think?
Cheers, Doru
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.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."
-- www.tudorgirba.com www.feenk.com
"Quality cannot be an afterthought."
-- www.tudorgirba.com www.feenk.com
"Every thing has its own flow."
-- www.tudorgirba.com www.feenk.com
"Every thing should have the right to be different."
-- www.tudorgirba.com www.feenk.com
"Be rather willing to give than demanding to get."
On Fri, Aug 26, 2016 at 9:10 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 26 Aug 2016, at 08:49, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi,
My point of view is:
1) in code/core, we should use (we already said that with Camille in the past ;-)):
self environmentAt: #Blah
Object>>environmentAt: aSymbol ^ self class environmentAt: aSymbol
Object class>>environmentAt: aSymbol ...
The idea is that we can then customize name resolution, per object, per class and per module in the future.
+1
2) For scripting purpose, asClass is indeed useful (GTInspector, ...). I would start simple as said before, re-package it and add a rule as suggested by Denis. Now, I am not sure that making asClass supporting name resolution in another environment is really useful. And if we do it using thisContext, some developers may use that instead of "obj environmentAt: XXX" which would be bad.
I dislike a lot the thisContext resolution idea. If is bad is bad⦠and it will be bad also for scripting. I know, now it does not looks like adding value, but think about: #asClass is monolithic and #asClass with thisContext âlooks monolithicâ, IMO promoting a bad way of thinking problems in Pharo thus inducing confusion for non expert users.
This makes me think about DynamicVariables for some reason. Will we get interference in that "context" ? Phil
Esteban
my 2KÄ,
#Luc
2016-08-26 6:56 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Aug 26, 2016, at 6:37 AM, stepharo <stepharo@free.fr> wrote:
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.
Certainly. There are many points of view and many constraints. This is why it is so important that we all bring forward those constraints because only like this we can reach a global maximum.
So, about asClass, everyone agrees that it should be moved to another package. The open questions are: - do we add an automatic deprecation for those that use it in code, or - do we make use of thisContext to retrieve the environment? (or both)
Also, what about the asClassInEnvironment: method? Can it be used in code, or do we better discourage its usage altogether? I am thinking that if we have to write: #MyClass asClassInEnvironment: self class environment is even longer than: self environment at: #MyClass so, I think there is little point to it.
In fact, for scripting what I find useful is not so much less characters, but the lack of parentheses, hence unary methods. That is why asClass is worth being salvaged for scripting (even with a solution that is slower with thisContext), but the rest maybe can be removed. What do you think?
Cheers, Doru
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.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."
-- www.tudorgirba.com www.feenk.com
"Quality cannot be an afterthought." -- www.tudorgirba.com www.feenk.com
"Every thing has its own flow."
-- www.tudorgirba.com www.feenk.com
"Every thing should have the right to be different."
On Fri, Aug 26, 2016 at 8:49 AM, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi,
My point of view is:
1) in code/core, we should use (we already said that with Camille in the past ;-)):
self environmentAt: #Blah
Makes sense, looks nice.
Object>>environmentAt: aSymbol ^ self class environmentAt: aSymbol
Object class>>environmentAt: aSymbol ...
The idea is that we can then customize name resolution, per object, per class and per module in the future.
2) For scripting purpose, asClass is indeed useful (GTInspector, ...). I would start simple as said before, re-package it and add a rule as suggested by Denis. Now, I am not sure that making asClass supporting name resolution in another environment is really useful.
For me, #Symbol asClass is really for yet unknown things with scripts (build or configuration). To avoid those pesky errors in the loading process. I just love being able to do (#ConfigurationOfXYZ asClass project ... ) load in an image building script that doesn't yet have a clue of ConfigurationOfXYZ b/c Gofer will load the packages. Same story when loading specific packages based on a configuration file symbol. config: Config equipmentSupportPackageSpec: #EquipmentXYZSupportPackage. Config>>equipmentSupportPackage ^ self equipmentSupportPackageSpec asClass new I can live with the new way but this just feels handy as hell.
And if we do it using thisContext, some developers may use that instead of "obj environmentAt: XXX" which would be bad.
my 2KÄ,
Thanks for chiming in. Phil
#Luc
2016-08-26 6:56 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Aug 26, 2016, at 6:37 AM, stepharo <stepharo@free.fr> wrote:
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.
Certainly. There are many points of view and many constraints. This is why it is so important that we all bring forward those constraints because only like this we can reach a global maximum.
So, about asClass, everyone agrees that it should be moved to another package. The open questions are: - do we add an automatic deprecation for those that use it in code, or - do we make use of thisContext to retrieve the environment? (or both)
Also, what about the asClassInEnvironment: method? Can it be used in code, or do we better discourage its usage altogether? I am thinking that if we have to write: #MyClass asClassInEnvironment: self class environment is even longer than: self environment at: #MyClass so, I think there is little point to it.
In fact, for scripting what I find useful is not so much less characters, but the lack of parentheses, hence unary methods. That is why asClass is worth being salvaged for scripting (even with a solution that is slower with thisContext), but the rest maybe can be removed. What do you think?
Cheers, Doru
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.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."
-- www.tudorgirba.com www.feenk.com
"Quality cannot be an afterthought." -- www.tudorgirba.com www.feenk.com
"Every thing has its own flow."
-- www.tudorgirba.com www.feenk.com
"Every thing should have the right to be different."
Hi 2016-08-25 8:52 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
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).
We could also make #asClass as "always deprecated" method with automatic rewriting. So in tools people will always see that it is better to not use it. But for scripting it will work normally. Also if people will commit such code it will become dirty very fast and always. And they will need to fix it
Yes this is what I was thinking too :)
Hi
2016-08-25 8:52 GMT+02:00 Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>>:
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).
We could also make #asClass as "always deprecated" method with automatic rewriting. So in tools people will always see that it is better to not use it. But for scripting it will work normally. Also if people will commit such code it will become dirty very fast and always. And they will need to fix it
Le 25/8/16 à 08:34, Yuriy Tymchuk a écrit :
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:?
Why not if it helps people :)
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
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. #SomeSymbol asClass looks very practical and cleaner that looking the class dictionary with at: #SomeSymbol 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
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 <mailto: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
participants (10)
-
Ben Coman -
Denis Kudriashov -
Esteban Lorenzano -
Guille Polito -
Luc Fabresse -
phil＠highoctane.be -
philippe.back＠highoctane.be -
stepharo -
Tudor Girba -
Yuriy Tymchuk