Is there a convention for naming keywork arguments that should have a boolean value?
When it's not a boolean, it seems the convention is
value: aValue
That doesn't seem right for booleans though. I'd end up with arguments like
expensive: anExpensive
--- Mark Volkmann
On Fri, 2008-09-26 at 17:02 -0500, Mark Volkmann wrote:
Is there a convention for naming keywork arguments that should have a boolean value?
When it's not a boolean, it seems the convention is
value: aValue
That doesn't seem right for booleans though. I'd end up with arguments like
expensive: anExpensive
There is no strict rule to it but I think here the majority follows some "hint what to expect" rule. That means you name the argument after the class of the argument.
expensive: anExpensive
you would write if the argument is an object with class Expensive. If it is a boolean you can write
expensive: aBoolean
Norbert
"Norbert" == Norbert Hartl norbert@hartl.name writes:
Norbert> There is no strict rule to it but I think here the majority Norbert> follows some "hint what to expect" rule. That means you name Norbert> the argument after the class of the argument.
Norbert> expensive: anExpensive
If I recall, according to Smalltalk Best Practice Patterns (the seminal patterns book for Smalltalk), you want the attribute to be of the form "isProperty":
isExpensive := true.
which means that "expensive:" shouldn't be a setter. In fact, said book states that you should have "be" methods:
anObject beExpensive anObject beCheap
which would likely set isExpensive to true and false respectively, perhaps, or even 2 states out of a 3-state variable. Encapsulation! Because then you also have tests:
anObject isExpensive ifTrue: [ ... ]
or even (if you use it a lot):
anObject ifExpensive: [ ... ]
I've often argued that automatic creation of getters and setters is wrong. This is clearly an example of where automatic getters and setters lead you to bizarre code.
On Fri, 2008-09-26 at 18:05 -0700, Randal L. Schwartz wrote:
"Norbert" == Norbert Hartl norbert@hartl.name writes:
Norbert> There is no strict rule to it but I think here the majority Norbert> follows some "hint what to expect" rule. That means you name Norbert> the argument after the class of the argument.
Norbert> expensive: anExpensive
If I recall, according to Smalltalk Best Practice Patterns (the seminal patterns book for Smalltalk), you want the attribute to be of the form "isProperty":
isExpensive := true.
which means that "expensive:" shouldn't be a setter. In fact, said book states that you should have "be" methods:
anObject beExpensive anObject beCheap
which would likely set isExpensive to true and false respectively, perhaps, or even 2 states out of a 3-state variable. Encapsulation! Because then you also have tests:
anObject isExpensive ifTrue: [ ... ]
or even (if you use it a lot):
anObject ifExpensive: [ ... ]
I've often argued that automatic creation of getters and setters is wrong. This is clearly an example of where automatic getters and setters lead you to bizarre code.
Yes and even the grammar was bad :) I was just answering his question. Did you read at least the subject?
Norbert
beginners@lists.squeakfoundation.org
-
Mark Volkmann -
merlyn＠stonehenge.com -
Norbert Hartl