Best way to return int through an arg (3 choices)

[Marc Rochkind]

To return an int (for example) through an argument, one can use a class
with an integer field. Three ways to do it come to mind:

1. Define a class named, say, IntHolder, with a public field:

public class IntHolder {
public int value;
}

2. Similar to #2, but make the field private and provide get and set
methods.

3. Instead of defining your own class, use the existing class
org.omg.CORBA.IntHolder.

Normally, one wouldn't code a class when a suitable one already exists, but
bringing in anything from org.omg.CORBA only for its holder classes seems
silly to me. It might confuse the reader more than including an extra class
would.

Similarly, normally one makes fields private and provides access functions,
but perhaps holder classes for primitive types is an exception. When the
only purpose of the class is to hold a primitive-type field, get and set
seem like overkill.

So, I am inclined to use #1 above.

Opinions?

--Marc

 

[Joona I Palaste]

To return an int (for example) through an argument, one can use a class
with an integer field. Three ways to do it come to mind:

1. Define a class named, say, IntHolder, with a public field:

public class IntHolder {
public int value;
}

2. Similar to #2, but make the field private and provide get and set
methods.

3. Instead of defining your own class, use the existing class
org.omg.CORBA.IntHolder.

Normally, one wouldn't code a class when a suitable one already exists, but
bringing in anything from org.omg.CORBA only for its holder classes seems
silly to me. It might confuse the reader more than including an extra class
would.

Similarly, normally one makes fields private and provides access functions,
but perhaps holder classes for primitive types is an exception. When the
only purpose of the class is to hold a primitive-type field, get and set
seem like overkill.

So, I am inclined to use #1 above.

Opinions?

I would choose #2 instead if it were my code. I am opposed to public
fields in principle. And I agree with you that including CORBA just to
use one single class, which doesn't even do any object broking stuff,
is overkill.
Why do you have to use an int holder class anyway? What's wrong with
java.lang.Integer? Sure it's immutable, but can't you just construct a
new instance every time you need to change the value?

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Hasta la Vista, Abie!"
- Bart Simpson

 

[Marc Rochkind]

On 30 Jun 2003 20:26:06 GMT, Joona I Palaste <[email protected]>
wrote:


[snip]

Why do you have to use an int holder class anyway? What's wrong with
java.lang.Integer? Sure it's immutable, but can't you just construct a
new instance every time you need to change the value?

The issue is the type of the argument that will be used to return the
value, as in this example:

void m(X A) { ... code to change value of A ... }

where I want to return a result through the argument A.

I can't see how X can be Integer.

--Marc

 

[Miguel De Anda]

To return an int (for example) through an argument, one can use a class
with an integer field. Three ways to do it come to mind:

1. Define a class named, say, IntHolder, with a public field:

public class IntHolder {
public int value;
}

2. Similar to #2, but make the field private and provide get and set
methods.

3. Instead of defining your own class, use the existing class
org.omg.CORBA.IntHolder.

Normally, one wouldn't code a class when a suitable one already exists, but
bringing in anything from org.omg.CORBA only for its holder classes seems
silly to me. It might confuse the reader more than including an extra class
would.

Similarly, normally one makes fields private and provides access functions,
but perhaps holder classes for primitive types is an exception. When the
only purpose of the class is to hold a primitive-type field, get and set
seem like overkill.

So, I am inclined to use #1 above.

Opinions?

--Marc

Wow, all this trouble just to make a swap function...

 

[Michiel Konstapel]

To return an int (for example) through an argument, one can use a
class

with an integer field. Three ways to do it come to mind:

<snip>

4. Functions have a return value, so use it.

Seriously, why do you need to do it like this?
Michiel

 

[Miguel De Anda]

<snip>

4. Functions have a return value, so use it.

Seriously, why do you need to do it like this?
Michiel

Oh, I think you can use an array of length 1.

int[] a = new int[1];
a[0] = 10;

void foo(int[] b) {
b[0] *= 2;
}

Something like that might work.

 

[Adam Maass]

To return an int (for example) through an argument, one can use a class
with an integer field. Three ways to do it come to mind:

1. Define a class named, say, IntHolder, with a public field:

public class IntHolder {
public int value;
}

2. Similar to #2, but make the field private and provide get and set
methods.

3. Instead of defining your own class, use the existing class
org.omg.CORBA.IntHolder.

Normally, one wouldn't code a class when a suitable one already exists, but
bringing in anything from org.omg.CORBA only for its holder classes seems
silly to me. It might confuse the reader more than including an extra class
would.

Similarly, normally one makes fields private and provides access functions,
but perhaps holder classes for primitive types is an exception. When the
only purpose of the class is to hold a primitive-type field, get and set
seem like overkill.

So, I am inclined to use #1 above.

Opinions?

Use the function's return value.


Oh, you say it's a function that is *supposed* to alter the state of the
object it is passed. So write a class that encapsulates the state to be
passed, and treat it just like any other class. That is, it will probably
have private data and public accessors. Unless it's a conceptually a struct,
and doesn't have any methods of its own. (These are ugly but sometimes
useful.)


-- Adam Maass

 

[xarax]

To return an int (for example) through an argument, one can use a class
with an integer field. Three ways to do it come to mind:

1. Define a class named, say, IntHolder, with a public field:

public class IntHolder {
public int value;
}

Use a nested private static class when all you need is
to pass around a simple-minded container object within
your main class. Use a package-scoped container class
when you need to pass around the container within a
single package.

2. Similar to #2, but make the field private and provide get and set
methods.

This is good for passing simple-minded container classes
between different packages.

3. Instead of defining your own class, use the existing class
org.omg.CORBA.IntHolder.

Normally, one wouldn't code a class when a suitable one already exists, but
bringing in anything from org.omg.CORBA only for its holder classes seems
silly to me. It might confuse the reader more than including an extra class
would.

Don't even think about doing this.

Similarly, normally one makes fields private and provides access functions,
but perhaps holder classes for primitive types is an exception. When the
only purpose of the class is to hold a primitive-type field, get and set
seem like overkill.

Only use accessor/modifier methods when the container is
used across packages.

However, having said that, there are standard Java container
classes that have simple public fields, like Dimension and
Rectangle.

You could define your own "util" package and put some simple
container classes there for use by all of your packages,
similar in purpose to Dimension and Rectangle.

So, I am inclined to use #1 above.

Just look at the scope of how your container will be used
within a single class, a single package, or across packages.

Such container classes are very useful when you must
return several values from a single method call and also
help with type-safety.

 

[Dale King]

To return an int (for example) through an argument, one can use a class
with an integer field. Three ways to do it come to mind:

The best way is to not do it at all. The very fact that you are
contemplating it tells me that there is something seriously wrong with your
design. The solution is to fix the design not finding the least hackish way
to return values through an argument.

There are at least a dozen different ways to fix the design, but without
more information about what your problem really looks like it is not
possible to advise you on the best way to go.

 

[Marc Rochkind]

The best way is to not do it at all. The very fact that you are
contemplating it tells me that there is something seriously wrong with
your
design. The solution is to fix the design not finding the least hackish
way
to return values through an argument.

There are at least a dozen different ways to fix the design, but without
more information about what your problem really looks like it is not
possible to advise you on the best way to go.

Hmmm... I think your first and last sentences are contradictory, but I
think I know what you meant... ;-)

But, since you asked...

I'm writing a Java interface to POSIX/SUS, and my goal is to be as faithful
to the C binding as possible, as this is intended primarily as an
educational tool.

There are POSIX/SUS functions like this:

pid_t waitpid(pid_t pid, int *stat_loc, int options);

One could, of course, define a class called, say WaitResult, that included
fields for both the process ID and the status, and perhaps that would be a
good idea if the goal were to design the best interface from the Java
perspective. But, if the goal is to teach waitpid and how it works, then
it's better to return the pid_t as the value of the method and to return
the status through the 2nd argument. Also, this allows the 2nd argument to
be null, which indicates that the status isn't wanted.

I expect that in the end the Java binding will be widely used from Jython,
as that will provide an interactive way to exercise the POSIX/SUS system
calls. An excellent educational tool, in my opinion.

I will hae reached my goal if one can make the POSIX/SUS calls from
Java/Jython by reading only the SUS, without referring to any separate
documentation (e.g., JavaDocs) for the Java/Jython binding at all.

--Marc

 

[Miguel De Anda]

"Dale King" <Dale[dot][email protected]> wrote in message

The best way is to not do it at all. The very fact that you are
contemplating it tells me that there is something seriously wrong with your
design. The solution is to fix the design not finding the least hackish way
to return values through an argument.

There are at least a dozen different ways to fix the design, but without
more information about what your problem really looks like it is not
possible to advise you on the best way to go.

I don't see anything wrong with modifying parameters to a routine, if
they are documented well. I've even worked in shops where we had
special naming for in/out vars.

There are always different reasons for doing things, and how you do
them is part of what you are trying to achieve. Sometimes it's simply
more efficient to modify a param to a function.

I can think of when you would modify parameters... whenever you need more
than 1 "return" value. Like if you are updating x and y coords... like a
rotation function or something.

 

[Joona I Palaste]

"Dale King" <Dale[dot][email protected]> wrote in message

To return an int (for example) through an argument, one can use a class
with an integer field. Three ways to do it come to mind:

The best way is to not do it at all. The very fact that you are
contemplating it tells me that there is something seriously wrong with your
design. The solution is to fix the design not finding the least hackish way
to return values through an argument.

There are at least a dozen different ways to fix the design, but without
more information about what your problem really looks like it is not
possible to advise you on the best way to go.

I don't see anything wrong with modifying parameters to a routine, if
they are documented well. I've even worked in shops where we had
special naming for in/out vars.

There are always different reasons for doing things, and how you do
them is part of what you are trying to achieve. Sometimes it's simply
more efficient to modify a param to a function.

I can think of when you would modify parameters... whenever you need more
than 1 "return" value. Like if you are updating x and y coords... like a
rotation function or something.

This is exactly why I wish Java had functional-style tuple types. This
could be done very easily with:

public void doIt() {
int x;
int y;
(x, y) = getCoordinates();
}
public (int, int) getCoordinates() {
int x = getXCoordinate();
int y = getYCoordinate();
return (x, y);
}

The only problem I could ever envision in this context would be what in
the world would happen if we were assigning a tuple value into a tuple
of variables where the same variable occurs more than once. For example:

int x;
(x, x) = (1, 2);

What the heck should this do?

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"And according to Occam's Toothbrush, we only need to optimise the most frequent
instructions."
- Teemu Kerola

 

[pete kirkham]

This is exactly why I wish Java had functional-style tuple types. This
could be done very easily with:

public void doIt() {
int x;
int y;
(x, y) = getCoordinates();
}
public (int, int) getCoordinates() {
int x = getXCoordinate();
int y = getYCoordinate();
return (x, y);
}

The only problem I could ever envision in this context would be what in
the world would happen if we were assigning a tuple value into a tuple
of variables where the same variable occurs more than once. For example:

int x;
(x, x) = (1, 2);

What the heck should this do?

I'd vote that the tuple gets expanded to an array of the most specific
common type (in this case int), and the assignments done in left to
right order, so that the above declaration has the same effect as:

public void doIt() {
int x;
int y;

int[] _value = getCoordinates();
x = _value[0];
y = _value[1];
}

public int[] getCoordinates() {
int x = getXCoordinate();
int y = getYCoordinate();

int[] _return = new int [2];
_return[0] = x;
_return[1] = y;
return _return;
}

so you'd be able, with the right tool for the macro expansion, get the
same effect with java-as-it-stands without the pain.

You can't trap the multiple assigments at compile time as arrays are
valid assigment targets:
(a, a[j])=foo()
may or may not write the same slot twice, so forcing them to be done
left-to-right is about all that can be done.

I'd also allow

(x, void) = getCoordinates()

which would set x to the first value and do nothing with the second.

Someday I'll get round to writing a slack java compiler/preprocessor
that'll do this stuff (unless you know of one already).


Pete

 

[Miguel De Anda]

This is exactly why I wish Java had functional-style tuple types. This
could be done very easily with:

public void doIt() {
int x;
int y;
(x, y) = getCoordinates();
}
public (int, int) getCoordinates() {
int x = getXCoordinate();
int y = getYCoordinate();
return (x, y);
}

The only problem I could ever envision in this context would be what in
the world would happen if we were assigning a tuple value into a tuple
of variables where the same variable occurs more than once. For example:

int x;
(x, x) = (1, 2);

What the heck should this do?

I think ML works like this.

 

[Dale King]

"Dale King" <Dale[dot][email protected]> wrote in message

To return an int (for example) through an argument, one can use a class
with an integer field. Three ways to do it come to mind:


The best way is to not do it at all. The very fact that you are
contemplating it tells me that there is something seriously wrong with your
design. The solution is to fix the design not finding the least

hackish

way

I don't see anything wrong with modifying parameters to a routine, if
they are documented well. I've even worked in shops where we had
special naming for in/out vars.

There are always different reasons for doing things, and how you do
them is part of what you are trying to achieve. Sometimes it's simply
more efficient to modify a param to a function.

I can think of when you would modify parameters... whenever you need more
than 1 "return" value.

Which is circular reasoning. The "need" to return more than 1 thing falls
under my classification of something seriously wrong with your design.

Like if you are updating x and y coords... like a
rotation function or something.

That example does not qualify as returning more than one thing. You are
returing one thing, a coordinate, that just has more than one part. AWT
components do this through returning a Point object.

 

[Roedy Green]

Which is circular reasoning. The "need" to return more than 1 thing falls
under my classification of something seriously wrong with your design.

There appears to be a fundamental asymmetry in the universe. methods
NEED many inputs but pining for more than one OUTPUT is sign of moral
laxity.

I wonder if this prejudice against multi outputs simply has to do with
attachment to the current notation.

 

[Dale King]

There appears to be a fundamental asymmetry in the universe. methods
NEED many inputs but pining for more than one OUTPUT is sign of moral
laxity.

I wonder if this prejudice against multi outputs simply has to do with
attachment to the current notation.

It has to do with the fact that it is a very bad abstraction and programming
is all about abstractions. Only returning things through the return value is
a much better, cleaner, easier to understand abstraction. It is much easier
to understand a method doing only one thing rather than multiple things.

Depending on the impelementation it can also be dangerous and expose you to
breaks in encapsulation.

I still have yet to see a use of returns through parameters where that is a
good choice and not better handled in some other way. They are a necesary
evil in C and sometimes C++ (I program in C++ that does not have
exceptions). I have seen great atrocities committed using returns through
parameters.

 

[Dale King]

There appears to be a fundamental asymmetry in the universe. methods
NEED many inputs but pining for more than one OUTPUT is sign of moral
laxity.

I wonder if this prejudice against multi outputs simply has to do with
attachment to the current notation.

yes, multiple return values are very usefull. in matlab, they are used
in many functions, and no one calls them bad design.[/QUOTE]

Matlab is not OO so is not really a fair comparison. I agree that in some
languages returns through parameters are a necessary evil. That is not the
case in Java.

I do not know why some java programmers think multiple output means
bad design.

These below are examples of matlab functions with multiple return values.

We have an equivocation going on here. It is not the return of multiple
values, but the return of multiple "things". It is perfectly fine if a
method returns multiple values as long as they constitute a single logical
abstraction.

[M,N] = SIZE(X) for matrix X, returns the number of rows and
columns in X as separate output variables.

So, this is a single thing with multiple values. It is like getSize in Java
that returns a Dimension instance.

[Y,I] = MAX(X) returns the indices of the maximum values in vector I.
If the values along the first non-singleton dimension contain more
than one maximal element, the index of the first one is returned.

Your description did not quite make sense. I is a return value. But it
sounds like returning an array or some object would be the way you would do
it in Java.

[Y,Zf] = FILTER(B,A,X,Zi) gives access to initial and final
conditions, Zi and Zf, of the delays.

Again sounds like a case for an array or an object. In this case, it
probably makes more sense to create a filter object, but I'd have to study
the Matlab function a bit more to know the best design.

are the above bad designs becuase the functions return more than one
value? I do not think so.

No, because they are not returning completely unrelated things. They are
things that together form a logical abstraction. You should therefore create
the abstraction (i.e. an object) and return an instance of that abstraction
(there are at least a dozen other different ways to replace pass by
reference).

But since Matlab is not object oriented that is not really an option. So
Matlab uses multiple return values. I would say Matlab is not the best that
it can be because it does not let you express these abstractions.

I certainly see no compelling reason to add multiple return values to Java,
when Java does let you express these abstractions.