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