passing auxiliary data to call-backs and closures (was: pointer)

[Stefan Ram]

Newsgroups: comp.lang.c,comp.lang.java.programmer
Followup-To: comp.lang.java.programmer

Personally I consider all four of these interfaces flawed because
they do not allow for any reasonable way to pass auxiliary data
to the callback functions. (I don't consider variables declared
at file scope to be reasonable in this context.)

This is one place, where Java programming really shines.

In Java, you can't pass a call-back method to another method
at all, you can only pass a call-back object. So, say you
have a call

void qsort( base, nmemb, size, compar );

, then »compar« must be an object, and qsort will call its
»compare« method.

Now, what has this to do with auxiliary data?

An object has to be constructed, like

compar = new Compar( ... );

, and there, at the ellipsis "...", you can put whatever
auxiliary data you can dream of into your compar object.
No need for qsort to be aware of it, no means for qsort
to get in the way of this.

And this might be one reason against a certain kind
of closures in Java.

As soon as a method accepts a closure and in the case that
this is implemented in a way where a closure is a kind of
method, but /not/ a fully fledged object, this way to pass
auxiliary data won't work anymore.

Newsgroups: comp.lang.c,comp.lang.java.programmer
Followup-To: comp.lang.java.programmer

 

[Fred]

Newsgroups: comp.lang.c,comp.lang.java.programmer
Followup-To: comp.lang.java.programmer



  This is one place, where Java programming really shines.

  In Java, you can't pass a call-back method to another method
  at all, you can only pass a call-back object. So, say you
  have a call

void qsort( base, nmemb, size, compar );

  , then »compar« must be an object, and qsort will call its
  »compare« method.

  Now, what has this to do with auxiliary data?

  An object has to be constructed, like

compar = new Compar( ... );

  , and there, at the ellipsis "...", you can put whatever
  auxiliary data you can dream of into your compar object.
  No need for qsort to be aware of it, no means for qsort
  to get in the way of this.

  And this might be one reason against a certain kind
  of closures in Java.

  As soon as a method accepts a closure and in the case that
  this is implemented in a way where a closure is a kind of
  method, but /not/ a fully fledged object, this way to pass
  auxiliary data won't work anymore.

Trivial to do this in C. Just pass an array of structs to qsort,
and a comparison method that knows how to compare two different
instances of that struct.
The struct can contain anything.

 

[Roedy Green]

In Java, you can't pass a call-back method to another method
at all, you can only pass a call-back object. So, say you
have a call

the official name is a "delegate". See
http://mindprod.com/jgloss/delegate.html
http://mindprod.com/jgloss/callback.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

"For reason that have a lot to do with US Government bureaucracy, we settled on the one issue everyone could agree on, which was weapons of mass destruction."
~ Paul Wolfowitz 2003-06, explaining how the Bush administration sold the Iraq war to a gullible public.

 

[Arne Vajhøj]

Trivial to do this in C. Just pass an array of structs to qsort,
and a comparison method that knows how to compare two different
instances of that struct.
The struct can contain anything.

It is also trivial to do in Java, but we have to pass an
object, because Java can not pass a method - it lacks
delegates/anonymous methods/closures/lambda expresssions.

Arne

 

[Eric Sosman]

Trivial to do this in C. Just pass an array of structs to qsort,
and a comparison method that knows how to compare two different
instances of that struct.
The struct can contain anything.

As a long-time C programmer, I am humbled by your use of
the word "trivial" for a task I personally would find onerous.
How, exactly, would you pass ancillary data to the comparison
function without the expensive subterfuge of attaching said
ancillary data to every single struct being sorted?

Here's a typical use case: We've got a struct containing an
array of N assorted keys, and we wish to sort on the [k]'th of
those keys. We could, of course, write N different comparison
routines, one for each possible index, and call qsort() with
the [k]'th of those N routines, essentially using the program
counter as the ancillary data. But wouldn't it be nicer if we
could somehow smuggle the value of k into a single omnibus
comparator?

/* C code */
int compare(const void *pp, const void *qq) {
const struct FooBar *p = pp, *q = qq;
int k = get_smuggled_value(); /* How? */
Keytype kp = p->key[k], kq = q->key[k];
return kp < kq ? -1 : kp > kq ? +1 : 0;
}

What's the trivial implementation of get_smuggled_value()?
(It *is* trivial in Java, but I don't know how to do it in C
without resorting to a static outside-the-function variable.)

 

[Roedy Green]

What's the trivial implementation of get_smuggled_value()?
(It *is* trivial in Java, but I don't know how to do it in C
without resorting to a static outside-the-function variable.)

In Java you have to write an entire little class for every different
sort, unless you can parameterise it as Eric described above. This is
a bit of a bother. Even in COBOL you do this with a SORT verb, as in
my home brew language Abundance (which can do external sorts too). In
Java, I wrote the ComparatorCutter to crank out the boilerplate code
for a Comparator or Comparable. The generated code always compiles
first time. It works first time, and it is well commented. This takes
much of the sting out of Java's futziness.

It handles most cases, and gets you 90% of the way there for very
complex ones.

You fill in a form in an Applet selecting field names, field types,
ascending/descending, and copy the generated code into your program.


See http://mindprod.com/applet/comparatorcutter.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

"For reason that have a lot to do with US Government bureaucracy, we settled on the one issue everyone could agree on, which was weapons of mass destruction."
~ Paul Wolfowitz 2003-06, explaining how the Bush administration sold the Iraq war to a gullible public.

 

[Lew]

In Java you have to write an entire little class for every different
sort, unless you can parameterise it as Eric described above. This is
a bit of a bother. Even in COBOL you do this with a SORT verb, as in

Not really. Unless by "bit" you really mean, "very tiny amount". It's less
trouble to write a Comparator than to keep track of the function pointer
syntax for the last parameter of the C 'sort()' function. It's far less
trouble for the later maintainer to read and understand the Java code.