December 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Vocabulary

by StÃ©phane Ducasse

cool! On Dec 23, 2008, at 10:40 PM, David RÃ¶thlisberger wrote: > >> Did you check whether other parts used Vocabulary? > > ok, there was another reference that I removed as well. > > David > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 23, 2008

Re: [Pharo-project] there is a sixx left over in Object

by StÃ©phane Ducasse

Hi ramon Yes I know now I was wondering why we got this in the *sixx category? Stef On Dec 23, 2008, at 10:37 PM, Ramon Leon wrote: >> Subject: [Pharo-project] there is a sixx left over in Object >> >> sixxInstVarNamed: instVarName put: aValue >> "override if you like" >> self >> instVarAt: (self class instVarIndexFor: >> instVarName asString) >> put: aValue >> >> Does anybody know where is come from? > > It's from the SIXX package, see Universe / Persistence / SIXX. SIXX > is an > XML serializer/deserializer written in Smalltalk. > > Ramon Leon > http://onsmalltalk.com > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 23, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by StÃ©phane Ducasse

On Dec 23, 2008, at 10:41 PM, Lukas Renggli wrote: >> would a preference help? > > Not really. You don't want to explain that to users and ask them to > change their settings before loading Seaside code? > > <rant> What if we would integrate Code Critics in the ClassBuilder and > throw an error whenever we try to compile a class that does not > satisfy on of the included rules? For sure, that would lead to high > quality code. It is easy to imagine though, that such an approach > makes it nearly impossible to do anything useful anymore. </rant> Why anything useful anymore? hijakcing Uppercase for private instance variable is not really good. This Singleton is NOT a globally accessible variable so why using Uppercase just because the compiler is weak. > Code Critics can be run independently of the compilation and is able > to point out violations of common patterns, like the fact that > instance variables should be lowercase. Personally I try to follow > most Code Critics rules, even if it makes sense to do it different in > some cases. I am in favour of naming instance variables in lowercase, > however this is not something the compiler should enforce. It is. This is the job of the compiler to reject code not following basic rules. Of course you can externalize the checks. But then what is a valid program? But indeed we should run code critics and build a good set of rules. I would love to do that. > > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 23, 2008

Re: [Pharo-project] there is a sixx left over in Object

by Marcus Denker

On Tue, Dec 23, 2008 at 10:13 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > sixxInstVarNamed: instVarName put: aValue > "override if you like" > self > instVarAt: (self class instVarIndexFor: instVarName > asString) > put: aValue > > Does anybody know where is come from? It was in a changeset that I harvested (and I overlooked it). The package should be deleted. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Dec. 23, 2008

Re: [Pharo-project] Gepetto2 and Pharo

by Marcus Denker

Hi, I tried to build a Reflectivity image last week using the lastest Pharo and there where strange problems... I did not look closely, I have no idea what they are... I will check later (maybe after christmas). Marcus On Tue, Dec 23, 2008 at 9:17 PM, Alexandre Bergel <Alexandre.Bergel(a)inria.fr > wrote: > Hi Marcus, > > When I run in Pharo the 133 tests of Gepetto2, I have 119 passes, 6 > expected failures, 2 failures, and 6 errors. > Is there something in Pharo that would prevent Gepetto2 from running > correctly ? > > Alexandre > > > On 23 Dec 2008, at 15:31, Alexandre Bergel wrote: > > > Hi Marcus, > > > > Do you know whether Gepetto2 is know to work on Pharo? I am trying > > to make Christo (the code coverage tool) run on Pharo. > > > > (I ask for it publicly since someone else than Marcus may know). > > > > Cheers, > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Dec. 23, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by StÃ©phane Ducasse

On Dec 23, 2008, at 10:25 PM, Lukas Renggli wrote: >> Can you tell me which one so that I ask Janko to fix it? > > It is the class instance-variable Singleton in SwazooBenchmarks. > >>> Unfortunately Pharo throws a notification >>> (instance variables should begin with a lower case characters) when >>> loading that code. >> >> May be we should have a way to trap that exception. > > I don't think this will be the only problem we encounter. I reported > this issue, because I am afraid that Pharo makes porting unnecessary > hard and unnecessarily restricts the language. Sure please continue this is important to learn from that. >>> - class names and class-variable names are enforced to be uppercase >>> - class instance-variable names are enforced to be lowercase >> >> I really think that this is good. >> Else what is the point to have a syntax? > > This is not part of the Smalltalk syntax. The syntax only says that a > variable is a letter followed by zero or more letters or digits. But the books I read were really mentioning that the uppercase indicated scope. lower private upper global. I thought it is rather cool to have such conventions that are ready standing out. And this can be part of the syntax of a language. Why Smalltalker wants always not to care. A bit of regularity does not hurt. Then in that case why Class name do not start with lowercase and instance variables with Uppercase if the compiler allows it then this is cool let us use it. >>> - it is not possible to assign a new value to a method argument >> >> This was always like that in Smalltalk. Arguments are ready only. > > I am just giving examples, this was discussed before. > > Since arguments are exactly the same as temps, this is just something > the compiler is enforcing on us. Being able to assign to arguments is > extremely useful and makes code much easier to read. Almost all todays > programming languages (C, C++, C#, Java, Ruby, JavaScript, ...) allow > that. I may be wrong but I imagine that this has some impact on the produced byte code and probably Jitted code too. > > >>> - variable names are enforced to be unique in all scopes >> >> This is the limit of the current compiler and not having full block >> closure I imagine. > > What I ment was more the fact that it is not possible to give a > temp-var the same name as an inst-var of the owning class. I think that this kind of shadowing is really not a good idea. In VisualWorks you can do it and I really would hate code written that way because I would always have to keep in mind that only on certain methods the variable I see is not the instance variable of the object but a local You could argue that since you redefine the variable you know it and this could work because we have small methods but with code longer than a page it can be leading to bug. > Or an > inst-var the same name as a global-var. How this is possible since a global should be uppercased and a instance variable lowercase? > Again, most todays programming > languages allow that. This is an unnecessary restrictions. Can you show us a case where this is useful? in ambientalk I could be convinced but ambientalk as block srtucture (nested object). In languages with block structure it is convenient but in Smalltalk with its flat structure I do not see why this is so important? (C, C++, C#, Java, Ruby, JavaScript, ...) they do not have the same program structure than Smalltalk program. In VisualWorks you can have block argument having the same name as instance variable now it is really good? This means that you cannot access the instance variable from the block internal directly. Ok you can you use a self send. Now I think that using the same name for two lexically different variable is not really cool. >>> In my opinion the language should be as open as possible. >> >> No it should follow well specified rules. Else this is the mess. >> In Smalltalk uppercase are for global variables and lowercase for >> private. > > Anyway, we don't have to agree on Smalltalk in general ;-) > > The only problem I have right now is that Seaside with Swazoo doesn't > load into the latest Pharo, because the compiler disallows uppercase > class instance-variables. It is not an unsolvable problem, but we have > to figure out a nasty hack to make the load-script silently load the > code. And the maintainers of Package Universe and Monticello > Configurations will have to figure out similar patches to work around > the Pharo Class builder. I think that we should have a preference to deal with that. > > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 23, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Lukas Renggli

> would a preference help? Not really. You don't want to explain that to users and ask them to change their settings before loading Seaside code? <rant> What if we would integrate Code Critics in the ClassBuilder and throw an error whenever we try to compile a class that does not satisfy on of the included rules? For sure, that would lead to high quality code. It is easy to imagine though, that such an approach makes it nearly impossible to do anything useful anymore. </rant> Code Critics can be run independently of the compilation and is able to point out violations of common patterns, like the fact that instance variables should be lowercase. Personally I try to follow most Code Critics rules, even if it makes sense to do it different in some cases. I am in favour of naming instance variables in lowercase, however this is not something the compiler should enforce. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 23, 2008

Re: [Pharo-project] Vocabulary

by David RÃ¶thlisberger

> Did you check whether other parts used Vocabulary? ok, there was another reference that I removed as well. David

Dec. 23, 2008

Re: [Pharo-project] there is a sixx left over in Object

by Ramon Leon

> Subject: [Pharo-project] there is a sixx left over in Object > > sixxInstVarNamed: instVarName put: aValue > "override if you like" > self > instVarAt: (self class instVarIndexFor: > instVarName asString) > put: aValue > > Does anybody know where is come from? It's from the SIXX package, see Universe / Persistence / SIXX. SIXX is an XML serializer/deserializer written in Smalltalk. Ramon Leon http://onsmalltalk.com

Dec. 23, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Lukas Renggli

> Can you tell me which one so that I ask Janko to fix it? It is the class instance-variable Singleton in SwazooBenchmarks. >> Unfortunately Pharo throws a notification >> (instance variables should begin with a lower case characters) when >> loading that code. > > May be we should have a way to trap that exception. I don't think this will be the only problem we encounter. I reported this issue, because I am afraid that Pharo makes porting unnecessary hard and unnecessarily restricts the language. >> - class names and class-variable names are enforced to be uppercase >> - class instance-variable names are enforced to be lowercase > > I really think that this is good. > Else what is the point to have a syntax? This is not part of the Smalltalk syntax. The syntax only says that a variable is a letter followed by zero or more letters or digits. >> - it is not possible to assign a new value to a method argument > > This was always like that in Smalltalk. Arguments are ready only. I am just giving examples, this was discussed before. Since arguments are exactly the same as temps, this is just something the compiler is enforcing on us. Being able to assign to arguments is extremely useful and makes code much easier to read. Almost all todays programming languages (C, C++, C#, Java, Ruby, JavaScript, ...) allow that. >> - variable names are enforced to be unique in all scopes > > This is the limit of the current compiler and not having full block > closure I imagine. What I ment was more the fact that it is not possible to give a temp-var the same name as an inst-var of the owning class. Or an inst-var the same name as a global-var. Again, most todays programming languages allow that. This is an unnecessary restrictions. >> In my opinion the language should be as open as possible. > > No it should follow well specified rules. Else this is the mess. > In Smalltalk uppercase are for global variables and lowercase for > private. Anyway, we don't have to agree on Smalltalk in general ;-) The only problem I have right now is that Seaside with Swazoo doesn't load into the latest Pharo, because the compiler disallows uppercase class instance-variables. It is not an unsolvable problem, but we have to figure out a nasty hack to make the load-script silently load the code. And the maintainers of Package Universe and Monticello Configurations will have to figure out similar patches to work around the Pharo Class builder. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 23, 2008