On Fri, 29 Jan 2010 12:56:43 -0500, Andrei Alexandrescu <seewebsiteforem...@erdani.org> wrote:

So now we're down to proportions, nuance, and where "main" goes. You made my point. I win.

You just don't get it. declaring property or not is part of naming the function. Any naming convention either can have strict rules or not. You cited two very strict naming conventions, I cited a not-so-strict one, one that is open to interpretation.

A similar naming convention in Java is the "isX" being a boolean property. Well, that doesn't always work because english doesn't always follow strict rules. Same thing for properties.

I don't know what you think you've won. I never said properties make every possible function name intuitive.


I admit this is a good example where a judgement call comes into play, but we aren't all robots obeying every rule literally.

If that's not enough, I have many others. With braces or names, I obey rules literally without any trouble. The problem with @property is, there are too many exceptions, judgment calls, and edge cases.

We went through scores of threads dissecting the names for range methods and what they should be. Does that mean that ranges are useless because we had to waste so much time naming their functions? The fact that we are arguing over one stupid function for this long is mind-boggling. Drop the straw man and look at the big picture. MOST OF THE TIME it is useful and intuitive. If that's not worth anything to you, then I don't know what else to say.


There are sometimes exceptions in conventions, or at least the rule is subject to interpretation.

Which brings home my point: the entire business of deciding @property or not is a waste of everyone's time. There's no simple rule, and there's no advantage to be gained after having made the decision one way or another.

No, there is no simple rule, just like there's no simple rule for symbol names. If you spend the time to name your properties correctly, the intuition provided saves all your users from wasting time looking up the documentation. It saves reviewers from wasting time looking up documentation to understand what a coder is doing. It's not a waste of time if it has benefits, and it does. You just refuse to believe it.

-Steve

Reply via email to