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.
> 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
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
> 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
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.
> 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 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. -- Joe
Joe <yohan1...@nospam.space.com> wrote: > 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.
On Wed, 20 Mar 2002 09:32:37 -0500, Joe <yohan1...@nospam.space.com> wrote:
>psst did you hear what Neil Zanella said >> 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 >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.
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:
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. -------------------
On Tue, 19 Mar 2002 18:29:08 -0330, Neil Zanella <nzane...@cs.mun.ca> wrote:
>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.
See the thread "Java equivalent of a struct of pointers to functions?" from 2/12/02.
------------------- Send Sun a Message! Vote for JConfig here:
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. -------------------
> > 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.
> 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.
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 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.
> > 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.
> 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. 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.
> "Carl Gay" <carl...@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.
> > "Carl Gay" <carl...@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.
> > 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.
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.
> > > 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.
> 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.
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"?
> 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.
> > 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.
On Tue, 19 Mar 2002 18:29:08 -0330, Neil Zanella <nzane...@cs.mun.ca> wrote or quoted :
>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.
> > > 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?
> > > > 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
"Dale King" <Ki...@TCE.com> wrote in message news:3ca0a5a9@news.tce.com... > Since we already have a simple mechanism for combining state with > behavior, we don't need a more limited approach.
> > 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.
> > > 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.
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.
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. 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.
> > 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 }
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;
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?
|
