Hi,
> On Aug 26, 2016, at 6:37 AM, stepharo <steph...@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.tymc...@me.com> wrote:
>>>>>>>
>>>>>>> Just my 2 cents:
>>>>>>>
>>>>>>>
>>>>>>> instead of
>>>>>>>
>>>>>>> #name asClass
>>>>>>>
>>>>>>> we have to use
>>>>>>>
>>>>>>> self class environment at: #name.
>>>>>>>
>>>>>>>
>>>>>>> Maybe instead of #at: we can have #classNamed:? Or something similar?
>>>>>>> Because 1) it’s not obvious that the method will give you a class, what
>>>>>>> if in the future and environment can also have a mapping of something
>>>>>>> else like packages?
>>>>>>>
>>>>>>> Uko
>>>>>>>
>>>>>>>> On 25 Aug 2016, at 07:21, stepharo <steph...@free.fr> wrote:
>>>>>>>>
>>>>>>>> Hi guys
>>>>>>>>
>>>>>>>> We got a meeting at ESUG with all the compiler guys and james from
>>>>>>>> gemstone.
>>>>>>>>
>>>>>>>> Our goal is to have a full tool suite that can be parametrized by
>>>>>>>> environments (so that
>>>>>>>>
>>>>>>>> we can compile code in other space, or compile other code inside
>>>>>>>> pharo).
>>>>>>>>
>>>>>>>> I personnally started this effort one decade ago. Now the introduction
>>>>>>>>
>>>>>>>> of #asClass and friend is simply destroying all our efforts. There was
>>>>>>>> a discussion
>>>>>>>>
>>>>>>>> in the past but we are not listened.
>>>>>>>>
>>>>>>>> We will
>>>>>>>>
>>>>>>>> - packaged these extensions in a separate package
>>>>>>>>
>>>>>>>> - add rules to ban the use of such method in Pharo
>>>>>>>>
>>>>>>>> - fix all the use (again) to use the correct way to do it.
>>>>>>>>
>>>>>>>>
>>>>>>>> I can understand that for scripting this is easier but it cannot be at
>>>>>>>> that cost and impact.
>>>>>>>>
>>>>>>>> I hope that we will understand but we have to do something else than
>>>>>>>>
>>>>>>>> fixing code that breaks our effort.
>>>>>>>>
>>>>>>>>
>>>>>>>> Stef, Marcus, Guille and Luc
>>>>>>>>
>>>>>>>>
>>>>>> --
>>>>>> www.tudorgirba.com
>>>>>> www.feenk.com
>>>>>>
>>>>>> "It's not what we do that matters most, it's how we do it."
>>>>>>
>>>>>>
>>>>>>
>>>> --
>>>> www.tudorgirba.com
>>>> www.feenk.com
>>>>
>>>> "Quality cannot be an afterthought."
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Every thing has its own flow."
>>
>>
>>
>>
>>
>>
>>
>
>
--
www.tudorgirba.com
www.feenk.com
"Every thing should have the right to be different."
