Hello Forum!
I've been trying to pin down a pattern for using the prefixes "be_" and "is_" in methods. I've named a variable as <isConstrained>. Is it acceptable to name accessor methods in this case as #beConstrained and #beUnconstrained? I don't know that I like "self isConstrained: false/true". In general, what are the guidelines for using "be_"? Cheers, Eric |
Eric Taylor escribió:
> Hello Forum! > > I've been trying to pin down a pattern for using the prefixes "be_" and > "is_" in methods. > > I've named a variable as <isConstrained>. Is it acceptable to name > accessor methods in this case as #beConstrained and #beUnconstrained? I > don't know that I like "self isConstrained: false/true". > > In general, what are the guidelines for using "be_"? We tend to use the is* testing methods for testing the state of receiver, but instance variable is named without the is prefix. I.e. if you want to determine the visibility of an object, you name the instVar 'visible', and then you have two testing methods and two "toggling" methods. Object subclass: #FooClass instanceVariableNames: 'visible' classVariableNames: '' poolDictionaries: '' classInstanceVariableNames: '' Then you have two "testing" methods: #isVisible and #isHidden And two "toggling" methods: #beVisible (or #show), and #beHidden (or #hide). Plus you preserve the direct accessor to the "visible" property, which is useful in cases like: anObject visible: self selectionIsValid. Another good example is with 'enabled' instead of 'visible'. Personally I don't like the #isVisible: kind of selectors, to me the #is* are just for testing, not to use as setters. However it's just my point of view (and of some colleagues). Regards, -- Esteban |
Esteban,
I would agree with you and your colleagues. We do the same thing in Eiffel, except that "be_" there typically takes the form of "make_": visible, make_visible, and make_hidden. I must say, though, I think "be_" is rather ingenious. Cheers, Eric > -----Original Message----- > From: Esteban A. Maringolo [mailto:[hidden email]] > Posted At: Saturday, July 01, 2006 9:26 PM > Posted To: comp.lang.smalltalk.dolphin > Conversation: When to Use the Fiat Prefix "be_" in Methods? > Subject: Re: When to Use the Fiat Prefix "be_" in Methods? > > Eric Taylor escribió: > > Hello Forum! > > > > I've been trying to pin down a pattern for using the prefixes "be_" > > "is_" in methods. > > > > I've named a variable as <isConstrained>. Is it acceptable to name > > accessor methods in this case as #beConstrained and #beUnconstrained? I > > don't know that I like "self isConstrained: false/true". > > > > In general, what are the guidelines for using "be_"? > > We tend to use the is* testing methods for testing the state of > receiver, but instance variable is named without the is prefix. > > I.e. if you want to determine the visibility of an object, you name the > instVar 'visible', and then you have two testing methods and two > "toggling" methods. > > Object subclass: #FooClass > instanceVariableNames: 'visible' > classVariableNames: '' > poolDictionaries: '' > classInstanceVariableNames: '' > > Then you have two "testing" methods: #isVisible and #isHidden > And two "toggling" methods: #beVisible (or #show), and #beHidden (or > #hide). > > Plus you preserve the direct accessor to the "visible" property, which > is useful in cases like: > > anObject visible: self selectionIsValid. > > Another good example is with 'enabled' instead of 'visible'. > > Personally I don't like the #isVisible: kind of selectors, to me the > #is* are just for testing, not to use as setters. > > However it's just my point of view (and of some colleagues). > > > Regards, > > -- > Esteban |
Free forum by Nabble | Edit this page |