Hi, > On Aug 26, 2016, at 9:10 AM, Esteban Lorenzano <esteba...@gmail.com> wrote: > >> >> On 26 Aug 2016, at 08:49, Luc Fabresse <luc.fabre...@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 <tu...@tudorgirba.com>: >> 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." -- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."
