views:

298

answers:

9

One of my most common bugs is that I can never remember whether something is a method or a property, so I'm constantly adding or removing parentheses.

So I was wondering if there was good logic behind making the difference between calling on an object's properties and methods explicit.

Obviously, it allows you to have properties and methods that share the same name, but I don't think that comes up much.

The only big benefit I can come up with is readability. Sometimes you might want to know whether something is a method or a property while you're looking at code, but I'm having trouble coming up with specific examples when that would be really helpful. But I am a n00b, so I probably just haven't encountered such a situation yet. I'd appreciate examples of such a situation.

Also, are there other languages where the difference isn't explicit?

Anyways, if you could answer, it will help me be less annoyed every time I make this mistake ^-^.

UPDATE: Thanks everyone for the awesome answers so far! I only have about a week's worth of js, and 1 day of python, so I had no idea you could reference functions without calling them. That's awesome. I have a little more experience with java, so that's where I was mostly coming from... can anyone come up with an equally compelling argument for that to be the case in java, where you can't reference functions? Aside from it being a very explicit language, with all the benefits that entails :).

+1  A: 

Typically properties are accessors, and methods perform some sort of action. Going on this assumption, it's cheap to use a property, expensive to use a method.

Foo.Bar, for example, would indicate to me that it would return a value, like a string, without lots of overhead.

Foo.Bar() (or more likely, Foo.GetBar()), on the other hand, implies needing to retrieve the value for "Bar", perhaps from a database.

Properties and methods have different purposes and different implications, so they should be differentiated in code as well.

By the way, in all languages I know of the difference in syntax is explicit, but behind the scenes properties are often treated as simply special method calls.

jvenema
I agree that property-like accesses should be cheap, but I don't agree with the other half; lots of functions are very cheap to call.
Glenn Maynard
Not denying that, but this is a discussion of comparisons of *the same* method/property with *the same* name - which would you expect to have more overhead?
jvenema
I'd expect a getter (i.e. GetX) to have a fairly cheap implementation. I don't see that it implies a need to retrieve the value. Most getters I've seen simply return an attribute.
Winston Ewert
+3  A: 

I think you answered it yourself:

One of my most common bugs is that I can never remember whether something is a method or a property, so I'm constantly adding or removing parentheses.

Consider the following:

if (colorOfTheSky == 'blue')

vs:

if (colorOfTheSky() == 'blue')

We can tell just by looking that the first checks for a variable called colorOfTheSky, and we want to know if its value is blue. In the second, we know that colorOfTheSky() calls a function (method) and we want to know if its return value is blue.

If we didn't have this distinction it would be extremely ambiguous in situations like this.

To answer your last question, I don't know of any languages that don't have this distinction.

Also, you probably have a design problem if you can't tell the difference between your methods and your properties; as another answer points out, methods and properties have different roles to play. Furthermore it is good practice for your method names to be actions, e.g. getPageTitle, getUserId, etc., and for your properties to be nouns, e.g., pageTitle, userId. These should be easily decipherable in your code for both you and anyone who comes along later and reads your code.

Josh Leitzel
This is incorrect in Python for method names (not bare function names); `foo.colorOfTheSky` is a function call if `colorOfTheSky` is a property. I'm not crazy about this in general, but it's helpful if you need to provide a particular interface that exposes class attributes but need to implement it with function calls behind the scenes.
Glenn Maynard
@Glenn: Didn't know that; thanks for the info.
Josh Leitzel
+5  A: 

At least in JS, its because you can pass functions around.

var func = new Function();

you can then so something like

 var f = func
 f()

so 'f' and 'func' are references to the function, and f() or func() is the invocation of the function.

which is not the same as

var val = f();

which assigns the result of the invocation to a var.

For Java, you cannot pass functions around, at least like you can in JS, so there is no reason the language needs to require a () to invoke a method. But it is what it is.

I can't speak at all for python.

But the main point is different languages might have reasons why syntax may be necessary, and sometimes syntax is just syntax.

hvgotcodes
+11  A: 

All modern languages require this because referencing a function and calling a function are separate actions.

For example,

def func():
    print "hello"
    return 10
a = func
a()

Clearly, a = func and a = func() have very different meanings.

Ruby--the most likely language you're thinking of in contrast--doesn't require the parentheses; it can do this because it doesn't support taking references to functions.

Glenn Maynard
The reason why Ruby doesn't support taking references to functions, is because it is an object-oriented language, and thus doesn't *have* functions. It does, however, have *methods* and it *does* support taking references to methods.
Jörg W Mittag
You can always count on the Rubyites coming out of the bushes at any hint of a criticism of their language, usually with a parroted attempt to redefine the word "function".
Glenn Maynard
@Juan Pablo Califano: the main feature of a function is that it cannot have any side-effects. Ruby's methods *can* have side-effects, therefore they cannot be functions.
Jörg W Mittag
@Jörg W Mittag. I disagree. Let's take C, for example, a language that undoubtly has functions. These functions can definitely have side effects (and sometimes very ugly ones).
Juan Pablo Califano
@Jörg: that definition may be true in functional programming languages, but it is not what "function" means in procedural programming languages such as Python, Javascript, Java, C++, PHP, Perl, and so on.
Ned Batchelder
@Glenn Maynard: You say that Ruby doesn't support taking references to functions. The only way that this statement can be true is in the trivial sense that functions don't exist. If by "function" you mean "method" or "procedure" (both of which Ruby has), then your statement is not true, since Ruby *does* support taking references to both of them. In fact, the *sole reason* for the existence of procedures in Ruby is so that you *can* take references to them.
Jörg W Mittag
@Glenn Maynard: Also, I don't quite understand what you mean by "redefine the word function". The definition I am using is over a hundred years old, I believe and hasn't changed a bit, and I wouldn't even *dare* try to redefine it, since it was defined by people much smarter than me. Roughly: "A function is a 3-tuple `⟨D, C, F⟩` of sets, where `D` is the domain, `C` is the codomain and `F` is a set of 2-tuples `⟨a, b⟩`, such that `a ∈ D`, `b ∈ C` and `∀x ∈ C: x is the first-element of exactly one such 2-tuple`".
Jörg W Mittag
@Ned Batchelder: there's a reason those "procedural" programming languages you list are called "procedural", not "functional".
Jörg W Mittag
@Glenn Maynard: I don't perceive anything of what you wrote as "a hint of criticism". Even if it were true.
Jörg W Mittag
(Sorry, I'm not going to be trolled by someone claiming functions can't have side-effects; patently absurd arguments don't need to be refuted. Feel free to find somebody else's time to waste.)
Glenn Maynard
@Jörg: A function in the mathematical or FP sense can't have side effects, yes. But these... thingies in imperative languages that you can call and that may have side effects have also been called functions for centuries now. Like it or not: In a programming context, "function" will often refer to "impure callable".
delnan
That's not a file! A file's a tool that you use to smooth surfaces! They've been called that for hundreds of years, and words can only have *one* meaning. Don't you know *anything?*
Glenn Maynard
@Jörg: it would be really helpful if you could address the OP's question: can you show us how it is that Ruby both allows the omission of parentheses when calling functions/methods/procedures *and* allows references to functions/methods/procedures. And BTW: you also seem to be the only one using your definition of "function" in the Ruby world.
Ned Batchelder
@Ned Batchelder: Sure, no problem. The answer for procedures is actually easy: Ruby doesn't allow omitting the parentheses for procedures. Assuming `p` is a procedure (i.e. a `Proc` object): `p;#reference p.()#call`. For methods, assuming `o` is an object which has a method named `:m` defined somewhere in its ancestry: `o.m;#call o.method(:m)#reference`.
Jörg W Mittag
You can also use `p[]` and `p.call` for Procs and lambdas. So Ruby has 4 different ways to call a function, half of which are only applicable to a certain type of function, one of which both references and calls the function depending on its type, most of which are ugly and unnecessary looking. And don't forget all the subtle differences in behavior between methods, blocks, procs, and lambdas. What a mess. Ruby should take a cue from Javascript, where all functions behave exactly the same, and through that consistent behavior all manner of OO/functional/procedural/meta programing is supported.
MooGoo
+7  A: 

In languages like Python and JavaScript, functions are first–class objects. This means that you can pass functions around, just like you can pass around any other value. The parentheses after the function name (the () in myfunc()) actually constitute an operator, just like + or *) Instead of meaning "add this number to another number" (in the case of +), () means "execute the preceding function". This is necessary because it is possible to use a function without executing it — for example you may wish to compare it to another function using ==, or you may wish to pass it into another function, such as in this JavaScript example:

function alertSomething(message) {
    alert(message);
}

function myOtherFunction(someFunction, someArg) {
   someFunction(someArg);
}

// here we are using the alertSomething function without calling it directly
myOtherFunction(alertSomething, "Hello, araneae!"); 

In short: it is important to be able to refer to a function without calling it — this is why the distinction is necessary.

Ben Hodgson
Oh wow, I didn't know you could do that! That's a really great example.
araneae
+2  A: 

Because referencing and calling a method a two different things. Consider X.method being the method, so x.method == 'blue' would be false. You can try this: print a method of an object:


>>> class X(object):
...   def a(self):
...     print 'a'
...
>>> x=X()
>>> print x.a
<bound method X.a of <__main__.X object at 0x0235A910>>

knitti
+3  A: 

If you're having troubles, distinguishing between your properties and methods, you're probably not naming them very well.

In general, your methods should have a verb in them: i.e. write, print, echo, open, close, get, set, and property names should be nouns or adjectives: name, color, filled, loaded.

It's very important to use meaningful method and property names, without it, you'll find that you'll have difficulty reading your own code.

Andrew Dunn
It's actually usually a problem with things I didn't name. For instance, to use a TreeWalker object, lastChild() is a method but currentNode is a property. I guess when it makes sense that the current position would be stored, but it's not obvious that the last child wouldn't be. And what about obj.length, or obj.length()? In JS, length is a property of a string but in java it's a method... perhaps it SHOULD be getLength() but it isn't :P
araneae
If it's a method it is implied that the processor does a calculation to return a value, if it's a property then it is simply a value getting retrieved from the RAM. For example, currentNode is stored and retrieved, while for lastChild to be returned, the processor must first determine the number of elements in the node, then return the last value, as such the value of lastChild is not stored in memory, but calculated when needed. Same as obj.length[()], javascript stores the value, while java calculates it.
Andrew Dunn
Right. I understand the difference, I was just pointing out that in those two examples the method name didn't have verbs in them (lastChild() and length()) and that was code I didn't write myself.
araneae
In Python and JavaScript, you can make functions accessible as though they were properties, instead of using get* and set* methods. See http://ejohn.org/blog/javascript-getters-and-setters/ for JavaScript and http://adam.gomaa.us/blog/2008/aug/11/the-python-property-builtin/ for Python.
MatrixFrog
+2  A: 

In Java, I can think of two reasons why the () is required:

1) Java had a specific design goal to have a "C/C++ like" syntax, to make it easy for C and C++ programmers to learn the language. Both C and C++ require the parentheses.

2) The Java syntax specifically requires the parentheses to disambiguate a reference to an attribute or local from a call to a method. This is because method names and attribute / local names are declared in different namespaces. So the following is legal Java:

public class SomeClass {
    private int name;
    private int name() { ... }

    ...

    int norm = name;  // this one
}

If the () was not required for a method call, the compiler would not be able to tell if the labeled statement ("this one") was assigning the value of the name attribute or the result of calling the name() method.

Stephen C
I suspect #1 is the reason Java is like this; it's a very explicit language. #2 addresses the fact that methods and variables can have the same name in java. The inconsequential (imo) effect of eliminating () that would be that you simply would have to have unique names for methods and fields. I'm looking for something more catastrophic; certainly namespaces in java is a bit complicated, what with inheritance and all; perhaps there might be unintended consequences (or at least ones difficult for the compiler to work around) with that?
araneae
@araneae - there could well be other reasons. But the question is moot. Java is what Java is. Something as fundamental as this is not going to change.
Stephen C
+2  A: 

The difference isn't always explicit in VBA. This is a call to a Sub (i.e. a method with no return value) which takes no parameters (all examples are from Excel):

Worksheets("Sheet1").UsedRange.Columns.AutoFit

whereas this is accessing an attribute then passing it as a parameter:

MsgBox Application.Creator

As in the previous example, parentheses are also optional around parameters if there is no need to deal with the return value:

Application.Goto Worksheets("Sheet2").Range("A1")

but are needed if the return value is used:

iRows = Len("hello world")
barrowc