Re: [Pharo-dev] About asClass and friend

Here is an example where asClass is useful. Someone posts something in the mail list like this... Gofer it smalltalkhubUser: 'hernan' project: 'CodeGenerator'; configuration; loadDevelopment. CGSmalltalkExamples exampleNSISPharo4. and pure laziness (apparently a sign of a good

Re: [Pharo-dev] About asClass and friend

On Fri, Aug 26, 2016 at 10:07 AM, Guille Polito wrote: > Hi! > > 1) I think we are failing also at communicating one point better. It is > not that people is arguing against #asClass because it's ugly and bad and a > terrible villain. Ok, maybe a bit, but also: > >

Re: [Pharo-dev] About asClass and friend

On Fri, Aug 26, 2016 at 9:10 AM, Esteban Lorenzano wrote: > > On 26 Aug 2016, at 08:49, Luc Fabresse wrote: > > Hi, > > My point of view is: > > 1) in code/core, we should use (we already said that with Camille in the > past ;-)): > > self

Re: [Pharo-dev] About asClass and friend

On Fri, Aug 26, 2016 at 8:49 AM, Luc Fabresse 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 > Makes sense, looks nice. > > Object>>environmentAt: aSymbol >

Re: [Pharo-dev] About asClass and friend

Hi! 1) I think we are failing also at communicating one point better. It is not that people is arguing against #asClass because it's ugly and bad and a terrible villain. Ok, maybe a bit, but also: The point is that #asClass, as it looks handy and easy to use, it may not work in the

Re: [Pharo-dev] About asClass and friend

Hi, > On Aug 26, 2016, at 9:10 AM, Esteban Lorenzano wrote: > >> >> On 26 Aug 2016, at 08:49, Luc Fabresse wrote: >> >> Hi, >> >> My point of view is: >> >> 1) in code/core, we should use (we already said that with Camille in the >> past ;-)):

Re: [Pharo-dev] About asClass and friend

2016-08-26 9:10 GMT+02:00 Esteban Lorenzano : > > On 26 Aug 2016, at 08:49, Luc Fabresse 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 >

Re: [Pharo-dev] About asClass and friend

> On 26 Aug 2016, at 08:49, Luc Fabresse 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

Re: [Pharo-dev] About asClass and friend

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

Re: [Pharo-dev] About asClass and friend

Hi, > On Aug 26, 2016, at 6:37 AM, stepharo 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

Re: [Pharo-dev] About asClass and friend

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. Stef Hi, There exists already a method for that: Symbol>>asClassInEnvironment: But, what if we introduce:

Re: [Pharo-dev] About asClass and friend

Hi, > On Aug 25, 2016, at 10:10 PM, stepharo wrote: > Hi, There exists already a method for that: Symbol>>asClassInEnvironment: But, what if we introduce: Symbol>>asClassFrom: anObject ^ self asClassInEnvironment: anObject

Re: [Pharo-dev] About asClass and friend

Ah, I am using that a lot to parametrize software. On one hand Pharo is breaking with the past, on the other one it sticks with it as much as possible? #MeConfused asHell. This has nothing to do with complying with the past. Do you think seriously that if we could replace self class env:

Re: [Pharo-dev] About asClass and friend

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.

Re: [Pharo-dev] About asClass and friend

Yes this is what I was thinking too :) Hi 2016-08-25 8:52 GMT+02:00 Tudor Girba >: Furthermore, as #asClass is meant to be mainly used for convenience, not performance, I would also propose to make it lookup in thisContext and

Re: [Pharo-dev] About asClass and friend

Hi 2016-08-25 8:52 GMT+02:00 Tudor Girba : > 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 >

Re: [Pharo-dev] About asClass and friend

Hi, > On Aug 25, 2016, at 9:52 AM, stepharo wrote: > > >> Hi, >> >> There exists already a method for that: >> Symbol>>asClassInEnvironment: >> >> But, what if we introduce: >> >> Symbol>>asClassFrom: anObject >> ^ self asClassInEnvironment: anObject class

Re: [Pharo-dev] About asClass and friend

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

Re: [Pharo-dev] About asClass and friend

Le 25/8/16 à 08:34, Yuriy Tymchuk a écrit : 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:? Why not if it helps people :) Or something similar? Because 1) it’s not obvious that the method

Re: [Pharo-dev] About asClass and friend

Le 25 août 2016 08:53, "Tudor Girba" 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 > > ?

Re: [Pharo-dev] About asClass and friend

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

Re: [Pharo-dev] About asClass and friend

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

Re: [Pharo-dev] About asClass and friend

Ah, I am using that a lot to parametrize software. On one hand Pharo is breaking with the past, on the other one it sticks with it as much as possible? #MeConfused asHell. #SomeSymbol asClass looks very practical and cleaner that looking the class dictionary with at: #SomeSymbol Phil Phil Le

[Pharo-dev] About asClass and friend

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