G
Guest
The question of whether a function is an objectSomebody said:So function is not an object.
Except you can't create them with 'new',
so their lifetime options are kind'a limit.
will vary from one programming language to
another. In the C family, a function is not
a first-class object. In a functional language
it is. In Python, a function looks like a first-class
object. However, Python and functional languages
implement everything by reference, under the hood.
In most languages, to treat a function as parameter
to another function, we have to create a reference
to it. In the C family, the reference is a pointer.
C# has a clever approach to this problem with
delegates. I am not sure how delegates are
implemented by the compiler. The Java approach
to this problem is rather ponderous, but then
Java seems to take the long way around for a
lot of things that ought to be more direct.
In defense of Java, the designers were simply
trying to preserve consistency. Which reminds
me of a quotation from R.W. Emerson, "A foolish
consistency is a hobgoblin of little minds." No one
actually knows what that quotation means, but it
is often quoted whenever anyone brings up the
notion of "consistency."
The question of whether a function, in the sense
of a programming artifact, can have state will
depend on the design of that function. Ideally,
a function will not have its own state, but will
return information about the state of some
attribute of an object. Ideally, a function will
not have side-effects that change the state of
an attribute.
But we're talking about programming here so
ideals have nothing to do with anything. Under
the constraints of any existing programming
language, there are no ideals. Everything
we do is constrained by the rules of the
language we choose to use.
From a mathematical view, a function is not
an object. But that is another discussion for
another day.
Richard Riehle