function as an argument

[ndac]

Hello,

How should I pass a function as an argument?

Regards,
Pieter

[Lew]

Re: function as an argument

ndac wrote:

Hello,
>
How should I pass a function as an argument?

You cannot do it directly in Java, as you can in some other languages. You can
create a (possibly anonymous) class that implements the desired functionality
in an overridden supertype method, as the Runnable interface does:

Thread t = new Thread(
new Runnable()
{
public void run()
{
performSomeActi on();
)
} );
t.start();

Another invocation could define the run() method to do something very
different, and the Thread would run it the same way. These are sometimes
called "functor" classes.

So instead of passing a function, you pass a class that implements a supertype
with a known method for the called code to run.

-- Lew

[ndac]

Re: function as an argument

Lew wrote:

ndac wrote:

>Hello,
>>
>How should I pass a function as an argument?

>
You cannot do it directly in Java, as you can in some other languages. You
can create a (possibly anonymous) class that implements the desired
functionality in an overridden supertype method, as the Runnable interface
does:
>

Thanks Lew, this is what I was looking for.

[Mark Rafn]

Re: function as an argument

ndac <ndac@ndac.comw rote:

>How should I pass a function as an argument?

It depends on what you're trying to do. The basic answer is "you can't".
However, there are a couple of ways to get functionality that's similar to
passing in a method in other languages.

1) You can pass a java.lang.refle ct.Method. This is pretty close to passing a
function pointer, but probably a bit slower and you're likely to end up doing
contortions to get everything to work the way you want.

2) You can define an interface that has a method with the appropriate
signature, and pass an instance of a class which implements that interface.
java.lang.Runna ble is a good example: there are a lot of APIs which take a
Runnable, and call run() on it. They're used by doing something like:
SwingUtilities. invokeLater(new Runnable() {
public void run() {
// do something here.
// you CAN reference member variables (being careful with threading)
// and final local variables in this inner class).
}
});
Which instantiates an anonymous class that implements Runnable, and passes it
into invokeLater, which queues it up and later the event thread calls run() on
this object. This idiom is common in some parts of the API (Swing, threading),
and gets you pretty close to most uses of function pointers.

It's not quite a closure. There are proposals to create a closure type, but
they're insanely complicated in my opinion, and I hope someone comes up with a
better plan.
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/>

[Lew]

Re: function as an argument

Mark Rafn wrote:

It's not quite a closure. There are proposals to create a closure type, but
they're insanely complicated in my opinion, and I hope someone comes up with a
better plan.

Will closures allow us to make more maintainable, more robust code in a timely
fashion for our corporate and government clients, or are they just a nifty
feature that scratch programmers' "nifty" itch?

I have yet to discern a real-world need for closures that the functor idiom
does not supply.

-- Lew

[Mark Rafn]

Re: function as an argument

Lew <lew@nospam.lew scanon.comwrote :

>Mark Rafn wrote:

>It's not quite a closure. There are proposals to create a closure type, but
>they're insanely complicated in my opinion, and I hope someone comes up
>with a better plan.

>Will closures allow us to make more maintainable, more robust code in a timely
>fashion for our corporate and government clients, or are they just a nifty
>feature that scratch programmers' "nifty" itch?

This is a false dichotomy. The feature itself is neither good nor bad. Uses
of the feature can be good (in that your logic can be more accurately and
concisely expressed) or bad (in that you can obscure your logic with misused
idioms).
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/>

[Lew]

Re: function as an argument

Lew <lew@nospam.lew scanon.comwrote :

>Will closures allow us to make more maintainable, more robust code in a timely
>fashion for our corporate and government clients, or are they just a nifty
>feature that scratch programmers' "nifty" itch?

Mark Rafn wrote:

This is a false dichotomy. The feature itself is neither good nor bad. Uses
of the feature can be good (in that your logic can be more accurately and
concisely expressed) or bad (in that you can obscure your logic with misused
idioms).

Some evaluation of the feature is necessary to make a decision to include or
exclude it from Java. Many have called for closures to be part of Java.

I agree that language features can be used brilliantly or badly. My question
was supposed to speak to the criteria by which we might alter the Java
language, which implies some metric of utility or "goodness" when weighing
against putative costs like "language bloat" or "insanely complicated".

I wonder if the feature when correctly used will make workaday programming
tasks easier or more efficient to perform, weighed against the utility of
existing idioms like functor classes and any possible disadvantages to
changing Java.

Obviously I am implicitly proposing a metric of utility, call it "incrementa l
reduction of effort to produce correct, stable, maintainable code". I am not
claiming this as correct, only as a first attempt to analyze the matter.

How should we evaluate a proposal for a new language feature such as closures?

-- Lew

[Mark Rafn]

Re: function as an argument

Lew <lew@nospam.lew scanon.comwrote :

>Some evaluation of the feature is necessary to make a decision to include or
>exclude it from Java. Many have called for closures to be part of Java.

True and true. I'm in complete agreement that I haven't heard the killer use
for closures that would justify it to me. I believe the language wonks,
though, when they say it adds a lot of expressive power. I can imagine that
idioms develop around it which are way easier to use and read than the current
use of anonymous classes.

http://crazybob.org/2006/10/java-closure-spectrum.html is a good starting
point for the proposals. It seems like the simpler syntax for anonymous
classes is pure goodness. The mess of parens and braces that are currently
required add nothing to readability or functionality.

More complicated things that make it a "true closure" by dealing with
non-final enclosing method variables seem unnecessary to me. It's possible
that there's a compelling reason for it, but I don't know it yet.
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/>