> 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. Esteban > > my 2Kč, > > #Luc > > 2016-08-26 6:56 GMT+02:00 Tudor Girba <tu...@tudorgirba.com > <mailto:tu...@tudorgirba.com>>: > Hi, > > > > > On Aug 26, 2016, at 6:37 AM, stepharo <steph...@free.fr > > <mailto: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 > >>>>>>> <mailto: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 > >>>>>>>> <mailto: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 <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." > > > > > >
