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
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
