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."
>
>