On Fri, 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. > 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 <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." >> >> >> >> >> >> > >
