4 ms·

Perhaps, but the simple habit of Model.foo() (for methods) and Model.bar for data would make it easier to spot when one is an attribute and one is a method.

yaur 13y ago
RubyMine at least will complain if you put the() after a method that doesn't need it. Coming from C# that lack of differentiation kind of irks me.
dperfect 13y ago
Any performance issues (which you brought up before the edit) should be entirely the concern of the class whose method is causing the issues. Anything on the outside shouldn't have to rely on syntactic clues to discover when something may be slower. If I care to call person.eye_color, I don't care (as the caller) how Person implements eye_color (it may be a simple attribute or do some ridiculously slow color calculation) - if I need the color, I need the color. Now, that's not to say that performance doesn't matter, just that any performance concerns should be addressed in Person, not in trying discourage caller from calling eye_color and trying to get at that value some other way.
phamilton 13y ago
That seems to fit the definition of leaky abstraction (an implementation detail influencing whether how you use it). Leaky abstractions are all over. That same logic would suggest that we should name our methods Model.foo_slow() and Model.bar_fast() because the execution speed is important and should be transparent to the caller. In practice, Model.foo() ends up often being memoized so that all but the first call are practically equivalent to accessing an attribute.
ryanto 13y ago
This won't work because it is not refactor proof. What happens when your system changes and Model.bar needs to become a method that does computation. Your suggestion violates the uniform access principle: http://en.wikipedia.org/wiki/Uniform_access_principle http://en.wikipedia.org/wiki/Uniform_access_principle

yaur 13y ago

RubyMine at least will complain if you put the() after a method that doesn't need it. Coming from C# that lack of differentiation kind of irks me.

dperfect 13y ago

Any performance issues (which you brought up before the edit) should be entirely the concern of the class whose method is causing the issues. Anything on the outside shouldn't have to rely on syntactic clues to discover when something may be slower. If I care to call person.eye_color, I don't care (as the caller) how Person implements eye_color (it may be a simple attribute or do some ridiculously slow color calculation) - if I need the color, I need the color. Now, that's not to say that performance doesn't matter, just that any performance concerns should be addressed in Person, not in trying discourage caller from calling eye_color and trying to get at that value some other way.

phamilton 13y ago

That seems to fit the definition of leaky abstraction (an implementation detail influencing whether how you use it). Leaky abstractions are all over. That same logic would suggest that we should name our methods Model.foo_slow() and Model.bar_fast() because the execution speed is important and should be transparent to the caller. In practice, Model.foo() ends up often being memoized so that all but the first call are practically equivalent to accessing an attribute.

ryanto 13y ago

This won't work because it is not refactor proof. What happens when your system changes and Model.bar needs to become a method that does computation. Your suggestion violates the uniform access principle: http://en.wikipedia.org/wiki/Uniform_access_principle http://en.wikipedia.org/wiki/Uniform_access_principle