class variable names: initial cap not enforced
Locked
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: class variable names: initial cap not enforced
|
|
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: class variable names: initial cap not enforced
|
|
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:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: class variable names: initial cap not enforced
|
|
In reply to this post by Stéphane Ducasse
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 <[hidden email]>: > 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: class variable names: initial cap not enforced
|
|
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 <[hidden email]>: >> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: class variable names: initial cap not enforced
|
|
In reply to this post by Cameron Sanders-3
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: class variable names: initial cap not enforced
|
|
In reply to this post by Cameron Sanders-3
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: class variable names: initial cap not enforced
|
|
In reply to this post by Cameron Sanders-3
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: class variable names: initial cap not enforced
|
|
In reply to this post by Stéphane Ducasse
> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: class variable names: initial cap not enforced
|
|
In reply to this post by Stéphane Ducasse
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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: class variable names: initial cap not enforced
|
|
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). _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |