[Pharo-project] class variable names: initial cap not enforced
I just loaded the code I have been developing in Pharo into Squeak (closure VM, using 4.10.2-7179web09.07 image base) and it had one complaint while loading: Squeak (seemingly) requires an initial cap on class variable names. [Maybe it allows it... but it popped up the debugger on an MC load.] Does Pharo allow the symbol to start with lower case by design, or was that act of omission? I am merely raising point to make certain it is an act of commission. -Cam
this is strange can you show us the class definition. We removed the hard check that enforced that classVariable should be capitalized and instvar starting with a lower case. Lukas wrote some smallLint rules to check that Stef On Jul 17, 2009, at 9:30 PM, Cameron Sanders wrote:
I just loaded the code I have been developing in Pharo into Squeak (closure VM, using 4.10.2-7179web09.07 image base) and it had one complaint while loading:
Squeak (seemingly) requires an initial cap on class variable names. [Maybe it allows it... but it popped up the debugger on an MC load.]
Does Pharo allow the symbol to start with lower case by design, or was that act of omission? I am merely raising point to make certain it is an act of commission.
-Cam
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
In Pharo, I originally create created the class with this: Object subclass: #FaFnBasicKeyLabelAssociations instanceVariableNames: '' classVariableNames: 'theSingleton' poolDictionaries: '' category: 'FA-FinanceMeta' And it compiled without complaint in Pharo. It was Squeak that complained during a load using Monticello. And just now, I reverted back to the lower case version (as exampled up above) and throws an "Error: theSingleton class variable name should be capitalized; proceed to include it anyway" ... and it lets me proceed. (I didn't read the full message previously and changed it.) So Squeak allows it, but complains where Pharo didn't. Sounds like it was "by design" in both cases. (I have three spinoff questions which I will put forth with a different subject line.) Thanks, Cam On Jul 17, 2009, at 6:04 PM, Stéphane Ducasse wrote:
this is strange can you show us the class definition.
We removed the hard check that enforced that classVariable should be capitalized and instvar starting with a lower case.
Lukas wrote some smallLint rules to check that
Stef
On Jul 17, 2009, at 9:30 PM, Cameron Sanders wrote:
I just loaded the code I have been developing in Pharo into Squeak (closure VM, using 4.10.2-7179web09.07 image base) and it had one complaint while loading:
Squeak (seemingly) requires an initial cap on class variable names. [Maybe it allows it... but it popped up the debugger on an MC load.]
Does Pharo allow the symbol to start with lower case by design, or was that act of omission? I am merely raising point to make certain it is an act of commission.
-Cam
which version are you using because this was removed at least 2 weeks ago? Stef
In Pharo, I originally create created the class with this:
Object subclass: #FaFnBasicKeyLabelAssociations instanceVariableNames: '' classVariableNames: 'theSingleton' poolDictionaries: '' category: 'FA-FinanceMeta'
And it compiled without complaint in Pharo.
It was Squeak that complained during a load using Monticello. And just now, I reverted back to the lower case version (as exampled up above) and throws an "Error: theSingleton class variable name should be capitalized; proceed to include it anyway" ... and it lets me proceed. (I didn't read the full message previously and changed it.) So Squeak allows it, but complains where Pharo didn't.
Sounds like it was "by design" in both cases.
(I have three spinoff questions which I will put forth with a different subject line.)
Thanks, Cam
On Jul 17, 2009, at 6:04 PM, Stéphane Ducasse wrote:
this is strange can you show us the class definition.
We removed the hard check that enforced that classVariable should be capitalized and instvar starting with a lower case.
Lukas wrote some smallLint rules to check that
Stef
On Jul 17, 2009, at 9:30 PM, Cameron Sanders wrote:
I just loaded the code I have been developing in Pharo into Squeak (closure VM, using 4.10.2-7179web09.07 image base) and it had one complaint while loading:
Squeak (seemingly) requires an initial cap on class variable names. [Maybe it allows it... but it popped up the debugger on an MC load.]
Does Pharo allow the symbol to start with lower case by design, or was that act of omission? I am merely raising point to make certain it is an act of commission.
-Cam
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Closure VM (Mac 4.1.1beta2U, using Damien's 4.10.2-7179web09.07 image base) with no updates, no patches, no fixes, nothing. Straight out of the box. And by the way, it does feel more responsive (faster) than the Pharo image. (discussed on a different thread.) On Jul 18, 2009, at 3:52 AM, Stéphane Ducasse wrote:
which version are you using because this was removed at least 2 weeks ago?
So you are questioning Squeak right now, correct (even though this is the Pharo list). -Cam
Stef
In Pharo, I originally create created the class with this:
Object subclass: #FaFnBasicKeyLabelAssociations instanceVariableNames: '' classVariableNames: 'theSingleton' poolDictionaries: '' category: 'FA-FinanceMeta'
And it compiled without complaint in Pharo.
It was Squeak that complained during a load using Monticello. And just now, I reverted back to the lower case version (as exampled up above) and throws an "Error: theSingleton class variable name should be capitalized; proceed to include it anyway" ... and it lets me proceed. (I didn't read the full message previously and changed it.) So Squeak allows it, but complains where Pharo didn't.
Sounds like it was "by design" in both cases.
(I have three spinoff questions which I will put forth with a different subject line.)
Thanks, Cam
On Jul 17, 2009, at 6:04 PM, Stéphane Ducasse wrote:
this is strange can you show us the class definition.
We removed the hard check that enforced that classVariable should be capitalized and instvar starting with a lower case.
Lukas wrote some smallLint rules to check that
Stef
On Jul 17, 2009, at 9:30 PM, Cameron Sanders wrote:
I just loaded the code I have been developing in Pharo into Squeak (closure VM, using 4.10.2-7179web09.07 image base) and it had one complaint while loading:
Squeak (seemingly) requires an initial cap on class variable names. [Maybe it allows it... but it popped up the debugger on an MC load.]
Does Pharo allow the symbol to start with lower case by design, or was that act of omission? I am merely raising point to make certain it is an act of commission.
-Cam
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
After I gave this response, I found several more emails on the topic. So nobody needs to respond further for my benefit: only respond if there is more that needs to be discussed. Thanks for the info and addressing the matter. Cheers, Cam On Jul 18, 2009, at 9:25 AM, Cameron Sanders wrote:
On Jul 18, 2009, at 3:52 AM, Stéphane Ducasse wrote:
which version are you using because this was removed at least 2 weeks ago?
So you are questioning Squeak right now, correct (even though this is the Pharo list).
I like the way that squeak raises a warning because this is an educational approach the system tells you that you are doing a mistake. Now people complained and we removed the warning and check in pharo and this is ok too. Stef On Jul 18, 2009, at 2:15 AM, Cameron Sanders wrote:
In Pharo, I originally create created the class with this:
Object subclass: #FaFnBasicKeyLabelAssociations instanceVariableNames: '' classVariableNames: 'theSingleton' poolDictionaries: '' category: 'FA-FinanceMeta'
And it compiled without complaint in Pharo.
It was Squeak that complained during a load using Monticello. And just now, I reverted back to the lower case version (as exampled up above) and throws an "Error: theSingleton class variable name should be capitalized; proceed to include it anyway" ... and it lets me proceed. (I didn't read the full message previously and changed it.) So Squeak allows it, but complains where Pharo didn't.
Sounds like it was "by design" in both cases.
(I have three spinoff questions which I will put forth with a different subject line.)
Thanks, Cam
On Jul 17, 2009, at 6:04 PM, Stéphane Ducasse wrote:
this is strange can you show us the class definition.
We removed the hard check that enforced that classVariable should be capitalized and instvar starting with a lower case.
Lukas wrote some smallLint rules to check that
Stef
On Jul 17, 2009, at 9:30 PM, Cameron Sanders wrote:
I just loaded the code I have been developing in Pharo into Squeak (closure VM, using 4.10.2-7179web09.07 image base) and it had one complaint while loading:
Squeak (seemingly) requires an initial cap on class variable names. [Maybe it allows it... but it popped up the debugger on an MC load.]
Does Pharo allow the symbol to start with lower case by design, or was that act of omission? I am merely raising point to make certain it is an act of commission.
-Cam
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes, I hate all these warning that the original compiler showed. It just slows the development down and limits the use of the language. There is really no need for the compiler to check for coding conventions, that's what Lint is for. Lukas 2009/7/18 Stéphane Ducasse <stephane.ducasse@inria.fr>:
this is strange can you show us the class definition.
We removed the hard check that enforced that classVariable should be capitalized and instvar starting with a lower case.
Lukas wrote some smallLint rules to check that
Stef
On Jul 17, 2009, at 9:30 PM, Cameron Sanders wrote:
I just loaded the code I have been developing in Pharo into Squeak (closure VM, using 4.10.2-7179web09.07 image base) and it had one complaint while loading:
 Squeak (seemingly) requires an initial cap on class variable names. [Maybe it allows it... but it popped up the debugger on an MC load.]
Does Pharo allow the symbol to start with lower case by design, or was that act of omission? I am merely raising point to make certain it is an act of commission.
-Cam
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
but lukas what are you saying? We removed them so what is the problem? Stef On Jul 18, 2009, at 8:28 AM, Lukas Renggli wrote:
Yes, I hate all these warning that the original compiler showed. It just slows the development down and limits the use of the language. There is really no need for the compiler to check for coding conventions, that's what Lint is for.
Lukas
2009/7/18 Stéphane Ducasse <stephane.ducasse@inria.fr>:
this is strange can you show us the class definition.
We removed the hard check that enforced that classVariable should be capitalized and instvar starting with a lower case.
Lukas wrote some smallLint rules to check that
Stef
On Jul 17, 2009, at 9:30 PM, Cameron Sanders wrote:
I just loaded the code I have been developing in Pharo into Squeak (closure VM, using 4.10.2-7179web09.07 image base) and it had one complaint while loading:
Squeak (seemingly) requires an initial cap on class variable names. [Maybe it allows it... but it popped up the debugger on an MC load.]
Does Pharo allow the symbol to start with lower case by design, or was that act of omission? I am merely raising point to make certain it is an act of commission.
-Cam
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
but lukas what are you saying? We removed them so what is the problem?
Yes, that's excellent. The original compiler complained and warned in a lot of places, unnecessarily restricting and baby-sit people. IMHO, the current implementation in Pharo is much better. I really like how it works now. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Jul 17, 2009, at 9:30 PM, Cameron Sanders wrote:
I just loaded the code I have been developing in Pharo into Squeak (closure VM, using 4.10.2-7179web09.07 image base) and it had one complaint while loading:
Squeak (seemingly) requires an initial cap on class variable names. [Maybe it allows it... but it popped up the debugger on an MC load.]
This is fun because I thought only previous version of pharo were doing that
Does Pharo allow the symbol to start with lower case by design, or was that act of omission? I am merely raising point to make certain it is an act of commission.
We had discussion in the past. class variables should be Uppercased instance variables should be lowercased. I believe that this is part of the semantics and that this is good that the compiler enforces that and reject bad code. Now since lukas complained loudly we removed the checks that we introduced earlier. People cannot say that we are not open and listening. Now the latest version allows you write any shitty code you want, to the point that you can totally confuse yourself by writing instance variable with Uppercase and the inverse too. Stef
participants (3)
-
Cameron Sanders -
Lukas Renggli -
Stéphane Ducasse