references to procedures
Neil Zanella
Hello,
It seems to me that Java does not support passing references to procedures
as methods arguments in the same way that C uses pointers to functions in
function calls. This means in order to such a thing the method would have
to be wrapped in a class and the class passed instead. This would make
sense considering the fact that Java was designed
with object orientation in mind.
Thanks,
Neil
Chris Sargent
Correct.
Java doesn't support pointers of any kind (although references are
essentially pointers, you can't manipulate them), which is good.
Rather than point to a function, you 'point' to an instance of a class
containing the function to invoke.
- sarge
Patricia Shanahan
Very commonly, the class will be an anonymous inner class that just
contains one method that calls the method you would point at in a
language with method pointers. For example, suppose you want to start a
new thread running myRunMethod in the current class. In a language with
method pointers Thread would probably be defined to accept a method
pointer representing what the thread should run. In Java, you pass it an
instance of Runnable.
new Runnable(){
public void run(){
myRunMethod();
}
}
creates an object that does the equivalent of a pointer to myRunMethod.
Patricia
Joe
programmed in C I learned C++ but we didn't do things like this.
--
Joe
"I bent my wookie" - Ralph Wiggum
Jon Skeet
> Chris is correct. I just wanted to ask when is this usefull ? I've never
> programmed in C I learned C++ but we didn't do things like this.
qsort() is the most obvious example, where you pass a pointer to a
comparison function.
--
Jon Skeet - <sk...@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
Chris Kelly
wrote:
>psst did you hear what Neil Zanella said
>> as methods arguments in the same way that C uses pointers to functions in
>programmed in C I learned C++ but we didn't do things like this.
For instance, the Windows and Mac APIs make extensive use of
callbacks. See RegisterClass on Windows, and quickdraw's drawing
functions on Mac.
-------------------
Send Sun a Message! Vote for JConfig here:
http://www.sys-con.com/java/readerschoice2002/nominationform.cfm
See the 'Best Class Library', 'Best Component', and 'Most Innovative
Product' categories. Thanks!
Get JConfig here: http://www.jconfig.com
Use JConfig to: enumerate the user's hard drives,
launch processes, get the file type of a file,
launch the user's default web browser, and much more.
-------------------
Chris Kelly
wrote:
See the thread "Java equivalent of a struct of pointers to functions?"
from 2/12/02.
Carl Gay
>
> psst did you hear what Neil Zanella said
> >
> > as methods arguments in the same way that C uses pointers to functions in
> > function calls. This means in order to such a thing the method would have
> > to be wrapped in a class and the class passed instead. This would make
> > sense considering the fact that Java was designed
> > with object orientation in mind.
> >
> programmed in C I learned C++ but we didn't do things like this.
It would be eye-opening to learn a functional language, though
it's unfashionable now that Object Obsession is the One True Way.
;-)
Actually, if you have a browser you have a reasonable way to experiment
with first-class functions since Javascript has them.
Dale King
news:3C9A1D66...@attbi.com...
It really is not very usefull to have references to functions. What will the
function act upon? Unless it is only a function that acts upon its
parameters and returns a result, there is not a real good use for just
pointing to a bare function that has no stated associated with it. In C you
had pointers to functions and they acted on global variables. That is not a
good thing.
It is much better to provide objects which have methods and have state
associated with them for the methods to act upon. That is the way to do it
in Java.
--
Dale King
Carl Gay
>
> "Carl Gay" <car...@attbi.com> wrote...
> > It would be eye-opening to learn a functional language, though
> > it's unfashionable now that Object Obsession is the One True Way.
> > ;-)
> >
> > Actually, if you have a browser you have a reasonable way to experiment
> > with first-class functions since Javascript has them.
>
> It really is not very usefull to have references to functions. What will the
> function act upon? Unless it is only a function that acts upon its
> parameters and returns a result, there is not a real good use for just
> pointing to a bare function that has no stated associated with it.
Most functional languages (by which I mean languages that support a
functional programming style, not purely functional languages) support
closures, so there is no reason a function can't contain encapsulated
state. It's also useful for first-class functions to do output, and
yes, to modify "global" state. (I put global in quotes because it's
really usually just module-level state, not truly global.) You can
even use closures to build OO systems if you wanted to.
Even if this were not the case, I can't believe anyone with much
experience using a functional style would say there's not much use in
functions that don't modify any external state. They are extremely
useful and common. Consider the equivalent of the Comparable class in
Java. All it really is is a compareTo function with window dressing
around it.
If you meant it's not very useful _in Java_, then I agree with you.
Java simply wasn't designed to support a functional style of
programming, so even if it had first class functions they would
be less useful than in, say, Common Lisp, where the language and
its libraries encourage you to use them all the time.
Dale King
> Dale King wrote:
> >
> > "Carl Gay" <car...@attbi.com> wrote...
> > > It would be eye-opening to learn a functional language, though
> > > it's unfashionable now that Object Obsession is the One True Way.
> > > ;-)
> > >
> > > Actually, if you have a browser you have a reasonable way to
experiment
> > > with first-class functions since Javascript has them.
> >
> > It really is not very usefull to have references to functions. What will
the
> > function act upon? Unless it is only a function that acts upon its
> > parameters and returns a result, there is not a real good use for just
> > pointing to a bare function that has no stated associated with it.
>
> Most functional languages (by which I mean languages that support a
> functional programming style, not purely functional languages) support
> closures, so there is no reason a function can't contain encapsulated
> state.
It sounds to me like in Java terms you would be talking about a method that
only operated on its parameters and returned a value, without modifying
external state. Note, I left that possibility open as an exception.
Of course, such a thing still works well as an object in this case and since
it would be immutable, can be done with a singleton.
> It's also useful for first-class functions to do output, and
> yes, to modify "global" state. (I put global in quotes because it's
> really usually just module-level state, not truly global.) You can
> even use closures to build OO systems if you wanted to.
But, modifying globals is bad practice. And yes, I striggled with putting
the word global on it. In Java it would be static, but static in C means
private (in some cases) and I was trying to stay language neutral.
> Even if this were not the case, I can't believe anyone with much
> experience using a functional style would say there's not much use in
> functions that don't modify any external state. They are extremely
> useful and common. Consider the equivalent of the Comparable class in
> Java. All it really is is a compareTo function with window dressing
> around it.
Note, my point was not that their was no use for such things (which I did
not say). My point was that it is better to think of pointing to objects
that can have associated state. In the cases you are talking about, they
don't need state, but objects is a better approach than pointing at
functions themselves.
Pointing to functions leads to a more procedural style and modifying of
global or static state. That is what most of the people asking for
references to procedures are trying to do. They aren't thinking OO.
--
Dale King
Carl Gay
> > functional programming style, not purely functional languages) support
> > closures, so there is no reason a function can't contain encapsulated
> > state.
>
> It sounds to me like in Java terms you would be talking about a method that
> only operated on its parameters and returned a value, without modifying
> external state. Note, I left that possibility open as an exception.
No, I'm talking about closures. Functions that hold references to free
variables that were in scope when the method was created, but may or may
not still be in scope. I can't give you an example in Java since it
doesn't exist, but here's one in Dylan:
define method make-counter ()
let x = 0;
method ()
x := x + 1
end
end;
define constant my-counter = make-counter();
So the first time you call my-counter() it returns 1, the 2nd
time it returns 2, etc. In other words, my-counter a method that
holds a reference to a location on the heap, which no one else
can access.
> > It's also useful for first-class functions to do output, and
> > yes, to modify "global" state. (I put global in quotes because it's
> > really usually just module-level state, not truly global.) You can
> > even use closures to build OO systems if you wanted to.
>
> But, modifying globals is bad practice.
Heh. The fact is that "global" state exists in programs and you have
to put it somewhere. If in Java you have to wrap it in a class, that
doesn't make it any better practice than in another language where it
is at module level. It depends on many things, like what programmers
in that language are used to, how large the program is, how fine-grained
the modules are, etc. The really bad practice, in my opinion, is tying
yourself too tightly to one single paradigm. Especially to a low-level
language like Java. ;-)
> > Even if this were not the case, I can't believe anyone with much
> > experience using a functional style would say there's not much use in
> > functions that don't modify any external state. They are extremely
> > useful and common. Consider the equivalent of the Comparable class in
> > Java. All it really is is a compareTo function with window dressing
> > around it.
>
> Note, my point was not that their was no use for such things (which I did
> not say). My point was that it is better to think of pointing to objects
> that can have associated state. In the cases you are talking about, they
> don't need state, but objects is a better approach than pointing at
> functions themselves.
Sometimes it is. Sometimes it isn't. There are a lot of cases in
Java where having first-class functions would simplify things.
Sometimes, having to put things into classes just adds verbosity,
extra names to remember, and no real value. Sometimes, maybe even
most times, it's great. Again, I want to be able to use whichever
style is best for the job at hand.
> Pointing to functions leads to a more procedural style and modifying of
> global or static state.
This is interesting, because I find that Java forces me into a
much more procedural style! e.g., always having to hold intermediate
results in variables because most of the core language uses statement
rather than expression semantics. Do we mean completely different
things when we talk about "procedural style"?
As for leading to use of global or static state, I don't think so.
Perhaps you are assuming a non-OO language like C? In Dylan, for
example, all methods are first class, and all field access is done
through method invocation, so one routinely uses first-class functions
to act on object state, not usually module-level state.
> That is what most of the people asking for
> references to procedures are trying to do. They aren't thinking OO.
I don't really go in for religion. ;-) All things in moderation.
Dale King
Oh, that's much worse. My point still stands, that is much better handled as
an object. And we were talking about Java. The existence of such a bad
practice in other languages (the C standard library is full of such
non-thread-safe practices).
> > > It's also useful for first-class functions to do output, and
> > > yes, to modify "global" state. (I put global in quotes because it's
> > > really usually just module-level state, not truly global.) You can
> > > even use closures to build OO systems if you wanted to.
> >
> > But, modifying globals is bad practice.
>
> Heh. The fact is that "global" state exists in programs and you have
> to put it somewhere. If in Java you have to wrap it in a class, that
> doesn't make it any better practice than in another language where it
> is at module level.
Once again we were talking about Java. Having a function pointer still makes
little sense in Java.
> It depends on many things, like what programmers
> in that language are used to, how large the program is, how fine-grained
> the modules are, etc. The really bad practice, in my opinion, is tying
> yourself too tightly to one single paradigm. Especially to a low-level
> language like Java. ;-)
>
> > > Even if this were not the case, I can't believe anyone with much
> > > experience using a functional style would say there's not much use in
> > > functions that don't modify any external state. They are extremely
> > > useful and common. Consider the equivalent of the Comparable class in
> > > Java. All it really is is a compareTo function with window dressing
> > > around it.
> >
> > Note, my point was not that their was no use for such things (which I
did
> > not say). My point was that it is better to think of pointing to objects
> > that can have associated state. In the cases you are talking about, they
> > don't need state, but objects is a better approach than pointing at
> > functions themselves.
>
> Sometimes it is. Sometimes it isn't. There are a lot of cases in
> Java where having first-class functions would simplify things.
> Sometimes, having to put things into classes just adds verbosity,
> extra names to remember, and no real value. Sometimes, maybe even
> most times, it's great. Again, I want to be able to use whichever
> style is best for the job at hand.
Which in my experience is always OO.
> > Pointing to functions leads to a more procedural style and modifying of
> > global or static state.
>
> This is interesting, because I find that Java forces me into a
> much more procedural style! e.g., always having to hold intermediate
> results in variables because most of the core language uses statement
> rather than expression semantics. Do we mean completely different
> things when we talk about "procedural style"?
I think so.
--
Dale King
Carl Gay
>
> Oh, that's much worse. My point still stands, that is much better handled as
> an object.
Please explain what advantages an "object" would have in this case.
What my example showed was a very simple, opaque object that generates
successive integers.
> And we were talking about Java.
I was talking about functions in general since the message I originally
replied to on this thread seemed to be asking when first class functions
would be useful in general. I made reference to "functional languages"
several times and you didn't object until now.
> The existence of such a bad
> practice in other languages (the C standard library is full of such
> non-thread-safe practices).
It's no more or less thread safe than accessing an instance
variable without synchronization.
Dale King
> Dale King wrote:
> >
> > Oh, that's much worse. My point still stands, that is much better
handled as
> > an object.
>
> Please explain what advantages an "object" would have in this case.
> What my example showed was a very simple, opaque object that generates
> successive integers.
You're right it is an object and that is what it should be:
public class counter
{
private int x = 0;
public int next()
{
x++;
return x;
}
}
> > And we were talking about Java.
>
> I was talking about functions in general since the message I originally
> replied to on this thread seemed to be asking when first class functions
> would be useful in general. I made reference to "functional languages"
> several times and you didn't object until now.
Because I wasn't sure what your point was.
> > The existence of such a bad
> > practice in other languages (the C standard library is full of such
> > non-thread-safe practices).
>
> It's no more or less thread safe than accessing an instance
> variable without synchronization.
Except what are you going to do make it thread safe? In Java it would be
encapsulated in an object that can be used for synchronization, just by
synchronizing the method. Your only choice would be to add another one of
these persistant local variables for a synchronizing object.
Once again, I am not saying that such things don't exist in other languages,
but the best way to do it in Java is to think in terms of objects. And that
is not simply because that is what the language is forcing you to do. There
is nothing about your method that is better than making it an object.
--
Dale King
Roedy Green
>It seems to me that Java does not support passing references to procedures
>as methods arguments in the same way that C uses pointers to functions in
>function calls.
see "callback" and "delegate" in the Java glossary for what Java does
have to replace it. It has the same functionality, just a somewhat
more verbose syntax.
The java glossary is at
http://www.mindprod.com/jgloss.html
or http://209.139.205.39
--
eagerly seeking telecommuting programming work.
canadian mind products, roedy green
Patricia Shanahan
Dale King wrote:
>
> "Carl Gay" <car...@attbi.com> wrote in message
> news:3C9F8668...@attbi.com...
> > Dale King wrote:
> > >
> > > Oh, that's much worse. My point still stands, that is much better
> handled as
> > > an object.
> >
> > Please explain what advantages an "object" would have in this case.
> > What my example showed was a very simple, opaque object that generates
> > successive integers.
>
> You're right it is an object and that is what it should be:
Does that "is what it should be" mean in the context of Java, or in
general?
Clearly some ideas, such as a counter, can be represented by either an
object or a function closure.
In Java there is a biass towards objects, so one would expect to use an
object for it.
On the other hand, often the function closure syntax seems simpler and
cleaner. Is there anything that makes objects automatically and
generally superior to function closures for jobs that can be done by
either?
Patricia
Dale King
news:3C9FFEBA...@acm.org...
>
>
> Dale King wrote:
> >
> > "Carl Gay" <car...@attbi.com> wrote in message
> > news:3C9F8668...@attbi.com...
> > > Dale King wrote:
> > > >
> > > > Oh, that's much worse. My point still stands, that is much better
> > handled as
> > > > an object.
> > >
> > > Please explain what advantages an "object" would have in this case.
> > > What my example showed was a very simple, opaque object that generates
> > > successive integers.
> >
> > You're right it is an object and that is what it should be:
>
> Does that "is what it should be" mean in the context of Java, or in
> general?
The original answer was about Java.
> Clearly some ideas, such as a counter, can be represented by either an
> object or a function closure.
>
> In Java there is a biass towards objects, so one would expect to use an
> object for it.
>
> On the other hand, often the function closure syntax seems simpler and
> cleaner. Is there anything that makes objects automatically and
> generally superior to function closures for jobs that can be done by
> either?
For one, simply wider applicability. Some simple jobs can be done with
function closures, but more complex jobs they can't. Objects handle both
with ease. Since we already have a simple mechanism for combining state with
behavior, we don't need a more limited approach.
--
Dale King
Marshall Spight
> Since we already have a simple mechanism for combining state with
> behavior, we don't need a more limited approach.
Wow. That was *really* well put.
Marshall
Carl Gay
>
> "Patricia Shanahan" <pa...@acm.org>...
> >
> > On the other hand, often the function closure syntax seems simpler and
> > cleaner. Is there anything that makes objects automatically and
> > generally superior to function closures for jobs that can be done by
> > either?
>
> For one, simply wider applicability. Some simple jobs can be done with
> function closures, but more complex jobs they can't. Objects handle both
> with ease. Since we already have a simple mechanism for combining state with
> behavior, we don't need a more limited approach.
Note that I have never argued that they should be used in place of
OO in general, only that they (and first-class functions in general)
are extremely useful. In part this is because, as Patricia points
out, they are much more concise. There are times when it is just a
waste of everyone's brain cells to glorify something with its own
class. This is one of the many reasons why Java takes on the order
of 15 times the number of lines of code to do the same thing as
Common Lisp, and as much as I enjoy writing Java code, I can't see
this as a good thing.
Dale King
I fail to see how it is much more concise.
Here was your function:
define method make-counter ()
let x = 0;
method ()
x := x + 1
end
end;
Not being familiar with Dylan, how do I read out the value of x?
And here is an OO version of it:
public class counter
{
private int x = 0;
public int increment()
{
return ++x;
}
}
Why is yours more concise?
It is certainly much less powerful. With an object you can have multiple
methods acting on the common state. I can easily add a decrement method as
well.
--
Dale King
Roedy Green
or quoted :
> private int x = 0;
> public int increment()
> {
> return ++x;
> }
The problem with Java is methods sometimes need a private static or
private instance variable. There is no way to associate them with
just one method. This is bad from a maintenance programmer's point of
view. He would like to know that given methods won't be used
elsewhere.
I find myself sometimes smashing classes up into smaller ones simply
to make these associations clearer.
One way out of that might be to allow declarations of the form
static xxx
and
instance xxx
INSIDE methods. Then they are private to the method. They would be
handled just as if they had been declared outside, except they would
not be visible to other methods. You could even insist they have
unique names.
Such a language construct would not require a change in the JVM.
Carl Gay
>
> "Carl Gay" <car...@attbi.com> wrote ...
> >
> > Note that I have never argued that they should be used in place of
> > OO in general, only that they (and first-class functions in general)
> > are extremely useful. In part this is because, as Patricia points
> > out, they are much more concise. There are times when it is just a
> > waste of everyone's brain cells to glorify something with its own
> > class. This is one of the many reasons why Java takes on the order
> > of 15 times the number of lines of code to do the same thing as
> > Common Lisp, and as much as I enjoy writing Java code, I can't see
> > this as a good thing.
>
> I fail to see how it is much more concise.
Like I said, it depends on the language and libraries supporting a
functional style. In a functional language I have a collection of
things and I want to count the number of things that pass a certain
test, I might say
let x = 0;
map(method (item)
test(item) & x := x + 1;
end,
collection)
quick and easy, and anyone familiar with the language can read it
in an instant. Now let's do it in Java. I'll assume only arrays
instead of generalized collections, since the Java collection
hierarchy is so broken:
public class Counter {
private int x = 0;
public int increment () {
return ++x;
}
}
Counter counter = new Counter(); // oops, just heap allocated.
for (int i = 0; i < myArray.length; i++) {
if (myArray[i].test()) {
counter.increment();
}
}
So Dylan uses 4 content lines (5 if you insist on putting the test
and increment on different lines) and Java uses 8. On top of that,
you now have to know the interface for the Counter class, which is
basically a waste of brain cells since it doesn't provide anything
useful above using ++x directly. "Damn, was the method called
'increment' or 'inc' or ...? Can't remember, I guess I have to go
look at the Counter class. Now where was that again? ..." In the
Dylan version, the code is right there in front of you, no need to
go look anywhere. (Of course this is a bit silly with this simple
example, but you get the idea.)
Now let's assume you want to generalize this counting thingy so you
can count the items in any collection iff they pass a certain test.
Here's the Dylan version:
define method count-if (predicate, collection)
let x = 0;
map(method (item)
predicate(item) & x := x + 1
end,
collection);
x
end;
Count the even numbers: count-if(even?, collection)
Count the odd numbers: count-if(odd?, collection)
Now let's do it in Java:
class Util { // hmmm, where should this method go...?
public static int countIf (Predicate p, Object[] array) {
Counter counter = new Counter(); // oops, just heap allocated
for (int i = 0; i < array.length; i++) {
if (p.test(array[i])) {
counter.increment();
}
}
return counter.getValue(); // Counter needs a new method for this
}
}
interface Predicate {
boolean test(Object);
boolean test(int);
boolean test(float);
...
}
+2 lines for the Counter.getValue method.
Util.countIf(new Predicate() {
public boolean test (Object o) {
return ((Integer)o) % 2 == 0;
}
},
collection)
Util.countIf(new Predicate() {
public boolean test (Object o) {
return ((Integer)o) % 2 != 0;
}
},
collection)
(Pardon any typos please.)
> Not being familiar with Dylan, how do I read out the value of x?
Everything in Dylan uses expression semantics. The := operator
returns the assigned value and is the last expression in the
method. Same as "return ++x".
> It is certainly much less powerful. With an object you can have multiple
> methods acting on the common state. I can easily add a decrement method as
> well.
I don't mean to be rude, but have you ever used a functional language
much? Of course they can do that. What they can't do quite as easily
is represent inheritance semantics. I would use a class for that.
I would most likely use a class if I wanted to have multiple methods
too, but here's one of many ways you can do it with a closure:
define method make-counter ()
let x = 0;
method (#key delta = 1)
x := x + delta
end
end;
define constant my-counter = make-counter();
my-counter() => 1
my-counter() => 2
my-counter(delta: -1) => 1
etc
I know you'll say "but that's not a method", to which I reply
"so what? it does the same thing."
Dale King
news:hgl6au07ead2pp1du...@4ax.com...
> On Thu, 28 Mar 2002 12:09:00 -0500, "Dale King" <Ki...@TCE.com> wrote
> or quoted :
>
> > private int x = 0;
> > public int increment()
> > {
> > return ++x;
> > }
>
> The problem with Java is methods sometimes need a private static or
> private instance variable.
I know of no instance where this is NEEDED. It certainly could be used and
might actually be desirable, but I disagree with needed.
This however is getting off-topic and is making the tangent we are on the
main subject.
--
Dale King
Roedy Green
or quoted :
>I know of no instance where this is NEEDED. It certainly could be used and
>might actually be desirable, but I disagree with needed.
I often find myself wanting to declare private static constants inside
methods. They are for use ONLY inside that method, Why should they
have more visibility than desired?
Chris Smith
> On Fri, 29 Mar 2002 23:15:08 -0500, "Dale King" <Ki...@TCE.com> wrote
> or quoted :
>
> >I know of no instance where this is NEEDED. It certainly could be used and
> >might actually be desirable, but I disagree with needed.
>
> I often find myself wanting to declare private static constants inside
> methods. They are for use ONLY inside that method, Why should they
> have more visibility than desired?
No need. Just don't make them private or static, since those have no
meaning in the context of a local variable. I do this all the time, eg:
pubic void myMethod()
{
final int MAGIC_NUMBER = 7;
System.out.println("Magic number: " + MAGIC_NUMBER);
}
Chris Smith
Roedy Green
or quoted :
> final int MAGIC_NUMBER = 7;
may favourite use for named constants is case labels. They have to be
static finals. Grr.
This may be tidied when Java gets a Pascalian enum/set where you can
create named constants (without manually assigning them values) you
can use in case statements.
Chris Smith
> On Mon, 1 Apr 2002 21:10:03 -0700, Chris Smith <cds...@twu.net> wrote
> or quoted :
>
> > final int MAGIC_NUMBER = 7;
>
> may favourite use for named constants is case labels. They have to be
> static finals. Grr.
Nope. The JLS says this:
Case labels must be constant expressions (14.10)
The name of a final variable that is initialized from a literal
qualifies as a constant expression. (15.28, first and next-to-last
bullet points)
Moreover, the following code works fine, at least with the built-in
compiler in Eclipse, and according to the JLS sections above it should
work fine in any other compiler as well.
public class Test
{
public static void main(String[] args)
{
final int FIRST = 0;
final int SECOND = 1;
final int THIRD = 2;
switch (1)
{
case FIRST:
System.out.println("First");
break;
case SECOND:
System.out.println("Second");
break;
case THIRD:
System.out.println("Third");
break;
}
}
}
> This may be tidied when Java gets a Pascalian enum/set where you can
> create named constants (without manually assigning them values) you
> can use in case statements.
There are benefits of such a thing, certainly... what Java needs more
than that, though, is a switch statement in which case labels are not
required to be compile-time constants, and in which object references are
perfectly valid as labels (semantically, compared using the equals()
method in the order of occurrence of the case labels, though this could
be optimized in certain cases such as String in ways that preserve those
semantics).
Then, you could use the standard and well-liked Object method of
declaring non-numeric constants and use them in case labels just as
anything else.
Chris Smith