October 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] About the scope of classVariables

by Luc Fabresse

2011/10/7 Levente Uzonyi <leves(a)elte.hu>: > On Fri, 7 Oct 2011, Igor Stasenko wrote: > >> On 7 October 2011 11:16, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> >>> On 7 October 2011 08:42, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>> >>>>> I do not understand why classVariables cannot shadow globals and take >>>>> precedence over them. >>>>> When I define a classVariable the resolution should take classVariable >>>>> over global. >>>> >>>> Any kind of shadowing is disallowed in Smalltalk. >>>> >>>> I think this is part of the language design is quite broken and a >>>> rather static approach that is very strange in a dynamic language like >>>> Smalltalk. Not even Java has these kind of static restrictions. >>>> >>>>> Now what will happen if I define classVariable with a name that is ok >>>>> in my current image but will be present >>>>> in the future in the image I will load my code! >>>> >>>> Yes, this is the current semantics. The possibility to shadow globals >>>> would be very useful to Â replace globals in the context of a class >>>> hierarchy. I suggested already many years ago to replace all shadowing >>>> errors on all levels (temps, arguments, inst vars, class vars, pool >>>> vars, globals) with compiler warnings. >>> >>> I must be missing something. I thought StÃ©phane was talking about >>> something like >>> >>> Object subclass: #Foo >>> Â Â Â Â instanceVariableNames: '' >>> Â Â Â Â classVariableNames: 'OrderedCollection' >>> Â Â Â Â poolDictionaries: '' >>> Â Â Â Â category: 'BalloonTests-Fills' >>> >>> bar >>> Â Â Â Â OrderedCollection := Array. >>> Â Â Â Â (OrderedCollection with: 1) add: 1 >>> >>> but "Foo new bar" raises the expected "Error: This message is not >>> appropriate for this object". >>> >>> What am I missing? >> >> everything is ok: an #add message is not appropriate for Array. > > Frank tried to point out that shadowing a global with a class variable > actually works. yes. So I did not get Stef's problem. Luc > > > Levente > >> >>> >>> frank >>> >>>> Lukas >>>> >>>> -- >>>> Lukas Renggli >>>> www.lukas-renggli.ch >>>> >>>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >

Oct. 7, 2011

Re: [Pharo-project] About the scope of classVariables

by Levente Uzonyi

On Fri, 7 Oct 2011, Igor Stasenko wrote: > On 7 October 2011 11:16, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> On 7 October 2011 08:42, Lukas Renggli <renggli(a)gmail.com> wrote: >>>> I do not understand why classVariables cannot shadow globals and take precedence over them. >>>> When I define a classVariable the resolution should take classVariable over global. >>> >>> Any kind of shadowing is disallowed in Smalltalk. >>> >>> I think this is part of the language design is quite broken and a >>> rather static approach that is very strange in a dynamic language like >>> Smalltalk. Not even Java has these kind of static restrictions. >>> >>>> Now what will happen if I define classVariable with a name that is ok in my current image but will be present >>>> in the future in the image I will load my code! >>> >>> Yes, this is the current semantics. The possibility to shadow globals >>> would be very useful to Â replace globals in the context of a class >>> hierarchy. I suggested already many years ago to replace all shadowing >>> errors on all levels (temps, arguments, inst vars, class vars, pool >>> vars, globals) with compiler warnings. >> >> I must be missing something. I thought StÃ©phane was talking about something like >> >> Object subclass: #Foo >> Â Â Â Â instanceVariableNames: '' >> Â Â Â Â classVariableNames: 'OrderedCollection' >> Â Â Â Â poolDictionaries: '' >> Â Â Â Â category: 'BalloonTests-Fills' >> >> bar >> Â Â Â Â OrderedCollection := Array. >> Â Â Â Â (OrderedCollection with: 1) add: 1 >> >> but "Foo new bar" raises the expected "Error: This message is not >> appropriate for this object". >> >> What am I missing? > > everything is ok: an #add message is not appropriate for Array. Frank tried to point out that shadowing a global with a class variable actually works. Levente > >> >> frank >> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko. > >

Oct. 7, 2011

Re: [Pharo-project] About the scope of classVariables

by Igor Stasenko

On 7 October 2011 11:16, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 7 October 2011 08:42, Lukas Renggli <renggli(a)gmail.com> wrote: >>> I do not understand why classVariables cannot shadow globals and take precedence over them. >>> When I define a classVariable the resolution should take classVariable over global. >> >> Any kind of shadowing is disallowed in Smalltalk. >> >> I think this is part of the language design is quite broken and a >> rather static approach that is very strange in a dynamic language like >> Smalltalk. Not even Java has these kind of static restrictions. >> >>> Now what will happen if I define classVariable with a name that is ok in my current image but will be present >>> in the future in the image I will load my code! >> >> Yes, this is the current semantics. The possibility to shadow globals >> would be very useful to Â replace globals in the context of a class >> hierarchy. I suggested already many years ago to replace all shadowing >> errors on all levels (temps, arguments, inst vars, class vars, pool >> vars, globals) with compiler warnings. > > I must be missing something. I thought StÃ©phane was talking about something like > > Object subclass: #Foo > Â Â Â Â instanceVariableNames: '' > Â Â Â Â classVariableNames: 'OrderedCollection' > Â Â Â Â poolDictionaries: '' > Â Â Â Â category: 'BalloonTests-Fills' > > bar > Â Â Â Â OrderedCollection := Array. > Â Â Â Â (OrderedCollection with: 1) add: 1 > > but "Foo new bar" raises the expected "Error: This message is not > appropriate for this object". > > What am I missing? everything is ok: an #add message is not appropriate for Array. > > frank > >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> > > -- Best regards, Igor Stasenko.

Oct. 7, 2011

Re: [Pharo-project] About the scope of classVariables

by Frank Shearar

On 7 October 2011 08:42, Lukas Renggli <renggli(a)gmail.com> wrote: >> I do not understand why classVariables cannot shadow globals and take precedence over them. >> When I define a classVariable the resolution should take classVariable over global. > > Any kind of shadowing is disallowed in Smalltalk. > > I think this is part of the language design is quite broken and a > rather static approach that is very strange in a dynamic language like > Smalltalk. Not even Java has these kind of static restrictions. > >> Now what will happen if I define classVariable with a name that is ok in my current image but will be present >> in the future in the image I will load my code! > > Yes, this is the current semantics. The possibility to shadow globals > would be very useful to Â replace globals in the context of a class > hierarchy. I suggested already many years ago to replace all shadowing > errors on all levels (temps, arguments, inst vars, class vars, pool > vars, globals) with compiler warnings. I must be missing something. I thought StÃ©phane was talking about something like Object subclass: #Foo instanceVariableNames: '' classVariableNames: 'OrderedCollection' poolDictionaries: '' category: 'BalloonTests-Fills' bar OrderedCollection := Array. (OrderedCollection with: 1) add: 1 but "Foo new bar" raises the expected "Error: This message is not appropriate for this object". What am I missing? frank > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > >

Oct. 7, 2011

Re: [Pharo-project] About the scope of classVariables

by Lukas Renggli

Keep in mind that this will be quite a complicated change, as it has many consequences across the whole system. For example, if you allow shadowing of globals with class variables you need to start to recompile/patch some methods in the class hierarchy with any class variable change. Also you need to revise the handling of obsolete associations, because that will become more complicated with the possibility of having the same name on different levels. Lukas On 7 October 2011 09:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Oct 7, 2011, at 9:42 AM, Lukas Renggli wrote: > >>> I do not understand why classVariables cannot shadow globals and take precedence over them. >>> When I define a classVariable the resolution should take classVariable over global. >> >> Any kind of shadowing is disallowed in Smalltalk. >> >> I think this is part of the language design is quite broken and a >> rather static approach that is very strange in a dynamic language like >> Smalltalk. Not even Java has these kind of static restrictions. >> >>> Now what will happen if I define classVariable with a name that is ok in my current image but will be present >>> in the future in the image I will load my code! >> >> Yes, this is the current semantics. The possibility to shadow globals >> would be very useful to Â replace globals in the context of a class >> hierarchy. I suggested already many years ago to replace all shadowing >> errors on all levels (temps, arguments, inst vars, class vars, pool >> vars, globals) with compiler warnings. > > > We should fix that. > And start with ClassVariable and Pool lookup. It should take precedence over globals. > Now I have to prefix all my classVariables and this is bad (it gives a bad feeling). > > > > >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > -- Lukas Renggli www.lukas-renggli.ch

Oct. 7, 2011

Re: [Pharo-project] About the scope of classVariables

by StÃ©phane Ducasse

On Oct 7, 2011, at 9:42 AM, Lukas Renggli wrote: >> I do not understand why classVariables cannot shadow globals and take precedence over them. >> When I define a classVariable the resolution should take classVariable over global. > > Any kind of shadowing is disallowed in Smalltalk. > > I think this is part of the language design is quite broken and a > rather static approach that is very strange in a dynamic language like > Smalltalk. Not even Java has these kind of static restrictions. > >> Now what will happen if I define classVariable with a name that is ok in my current image but will be present >> in the future in the image I will load my code! > > Yes, this is the current semantics. The possibility to shadow globals > would be very useful to replace globals in the context of a class > hierarchy. I suggested already many years ago to replace all shadowing > errors on all levels (temps, arguments, inst vars, class vars, pool > vars, globals) with compiler warnings. We should fix that. And start with ClassVariable and Pool lookup. It should take precedence over globals. Now I have to prefix all my classVariables and this is bad (it gives a bad feeling). > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Oct. 7, 2011

Re: [Pharo-project] About the scope of classVariables

by Lukas Renggli

> I do not understand why classVariables cannot shadow globals and take precedence over them. > When I define a classVariable the resolution should take classVariable over global. Any kind of shadowing is disallowed in Smalltalk. I think this is part of the language design is quite broken and a rather static approach that is very strange in a dynamic language like Smalltalk. Not even Java has these kind of static restrictions. > Now what will happen if I define classVariable with a name that is ok in my current image but will be present > in the future in the image I will load my code! Yes, this is the current semantics. The possibility to shadow globals would be very useful to replace globals in the context of a class hierarchy. I suggested already many years ago to replace all shadowing errors on all levels (temps, arguments, inst vars, class vars, pool vars, globals) with compiler warnings. Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 7, 2011

[Pharo-project] About the scope of classVariables

by StÃ©phane Ducasse

Hi guys I do not understand why classVariables cannot shadow globals and take precedence over them. When I define a classVariable the resolution should take classVariable over global. Right now I have to prefix my classVariable to be able to define them. Now what will happen if I define classVariable with a name that is ok in my current image but will be present in the future in the image I will load my code! I have to check what paolo did in GNU because he changed something. I think that there is something really broken or I'm totally stupid. Stef

Oct. 7, 2011

Re: [Pharo-project] any news from the RPackage crew?

by StÃ©phane Ducasse

> Hi! > > There are some update problems in RPackage. Is there any progress? No. No time for pharo in this moment from my side. Do you have repeatable scenario? because we thought that we find it but this is when the test of systemnavigation are run, they let the system in a strange state. Stef

Oct. 6, 2011

Re: [Pharo-project] One Liners to Impress Your Friends

by Sven Van Caekenberghe

On 06 Oct 2011, at 16:58, Levente Uzonyi wrote: > Here's a version optimized for readibility & loc: > > Array streamContents: [ :primeStream | > | sieve | > sieve := Array new: 100 withAll: true. > 2 to: sieve size do: [ :each | > (sieve at: each) ifTrue: [ > primeStream nextPut: each. > each * each to: sieve size by: each do: [ :eachMultiple | > sieve at: eachMultiple put: false ] ] ] ]. That is indeed a cooler version. Thanks for the feedback, Levente ! Sven

Oct. 6, 2011