function as an argument
8 Message(s) by 3 Author(s) originally posted in java programming
| From: ndac |
Date: Monday, March 19, 2007
|
Hello,
How should I pass a
function as an argument?
Regards,
Pieter
| From: Lew |
Date: Monday, March 19, 2007
|
wrote in message:
Hello,
How should I pass a function as an argument?
You cannot do it directly in JAVA, as you can in some other
language s. 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 ()
{
performSomeAction();
)
} );
t.start();
Another invocation could define the run() method to do something very
different, and the Thread'd 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
| From: ndac |
Date: Monday, March 19, 2007
|
wrote in message:
wrote in message:
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.
| From: dagon |
Date: Monday, March 19, 2007
|
wrote in message:
How should I pass a function as an argument?
It depends on what you're trying to do. The basic answer is "you can not".
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.reflect.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.Runnable is a good example: there are a lot of
API s 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
thread ing)
// 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 (application
programming interface)(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@xxxxxxxxxxx
<http://www.dagon.net/>
| From: Lew |
Date: Tuesday, March 20, 2007
|
wrote in message:
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've yet to discern a real-world need for closures that the functor idiom
doesn't supply.
-- Lew
| From: dagon |
Date: Tuesday, March 20, 2007
|
wrote in message:
wrote in message:
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@xxxxxxxxxxx
<http://www.dagon.net/>
| From: Lew |
Date: Wednesday, March 21, 2007
|
wrote in message:
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?
wrote in message:
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 "incremental
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
| From: dagon |
Date: Wednesday, March 21, 2007
|
wrote in message:
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 have not heard the killer use
for closures that'd 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 do not know it yet.
--
Mark Rafn dagon@xxxxxxxxxxx
<http://www.dagon.net/>
Blogs related to function as an argument
Refunctoring
If we consider our Convert type to actually represent ‘anything that can convert aT to a U’, we call map a higher-order
function, since it takes a
function (from T to U) as an
argument. Whether or not to name this
function argument (to
...
closure mania!
The referenced
function could still be a static one, defined at compile time. But at that point we are already getting pretty close to first-order
functions. One line of
argument against adding closures to
Java is that “closures are a
...
Object-Oriented programming in ActionScript 3 vs Java
No class declaration is required for such a simple program, and the debug
function trace() can live its own class-independent life, as opposed to
Java’s println() doubly-wrapped in the classes System and PrintStream.
...
Java Script Closures
As far as I understand the concept you just use a
function as an argument for another
function like GDownloadUrl("data.xml",
function(data, responseCode) { var xml = GXml.parse(data) ... });. Could someone, or perhaps Bud in class,
...
Scala for Java programmers
create a List with "List"
function (which is actually // an object with "apply") var names : List[String] = List("
Java", "JavaScript") // :: is the cons operator // creates a new list with first element as "Scala" // and rest of the
...
Scala for Java programmers - Part 2
Use
java.lang.reflect.Method (but, you'll miss static type checking!) Method references can be passed as
argument whenever a
function type value is expected. object Main { def func(s: String) : boolean = { return s.
...