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

Discussion in 'Java' started by Marc Rochkind, Jun 30, 2003.

  1. 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
    Marc Rochkind, Jun 30, 2003
    #1
    1. Advertising

  2. Marc Rochkind <> scribbled the following:
    > 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 () ---------------------------\
    | 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
    Joona I Palaste, Jun 30, 2003
    #2
    1. Advertising

  3. On 30 Jun 2003 20:26:06 GMT, Joona I Palaste <>
    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
    Marc Rochkind, Jun 30, 2003
    #3
  4. "Marc Rochkind" <> wrote in message
    news:eek:...
    > 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...
    Miguel De Anda, Jun 30, 2003
    #4
  5. > 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
    Michiel Konstapel, Jun 30, 2003
    #5
  6. "Michiel Konstapel" <> wrote in message
    news:iF2Ma.1511$w3.387301@zonnet-reader-1...
    > > 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
    >
    >


    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.
    Miguel De Anda, Jul 1, 2003
    #6
  7. Marc Rochkind

    Adam Maass Guest

    "Marc Rochkind" <> wrote:
    > 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
    Adam Maass, Jul 1, 2003
    #7
  8. Marc Rochkind

    xarax Guest

    Marc Rochkind <> wrote in message news:<>...
    > 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.
    xarax, Jul 1, 2003
    #8
  9. Marc Rochkind

    Dale King Guest

    "Marc Rochkind" <> wrote in message
    news:eek:...
    > 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.

    --
    Dale King
    Dale King, Jul 1, 2003
    #9
  10. On Tue, 1 Jul 2003 10:25:38 -0500, Dale King <Dale[dot]>
    wrote:

    > "Marc Rochkind" <> wrote in message
    > news:eek:...
    >> 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.
    >
    > --
    > Dale King
    >
    >
    >


    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
    Marc Rochkind, Jul 1, 2003
    #10
  11. "Keeger" <> wrote in message
    news:...
    > "Dale King" <Dale[dot]> wrote in message

    news:<>...
    > > "Marc Rochkind" <> wrote in message
    > > news:eek:...
    > > > 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.
    Miguel De Anda, Jul 2, 2003
    #11
  12. Miguel De Anda <> scribbled the following:
    > "Keeger" <> wrote in message
    > news:...
    >> "Dale King" <Dale[dot]> wrote in message

    > news:<>...
    >> > "Marc Rochkind" <> wrote in message
    >> > news:eek:...
    >> > > 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 () ---------------------------\
    | 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
    Joona I Palaste, Jul 3, 2003
    #12
  13. Marc Rochkind

    pete kirkham Guest

    Joona I Palaste wrote:

    > 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
    pete kirkham, Jul 3, 2003
    #13
  14. >
    > 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.
    Miguel De Anda, Jul 3, 2003
    #14
  15. Marc Rochkind

    Dale King Guest

    "Miguel De Anda" <> wrote in message
    news:8eGMa.117$...
    >
    > "Keeger" <> wrote in message
    > news:...
    > > "Dale King" <Dale[dot]> wrote in message

    > news:<>...
    > > > "Marc Rochkind" <> wrote in message
    > > > news:eek:...
    > > > > 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.


    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.
    --
    Dale King
    Dale King, Jul 7, 2003
    #15
  16. Marc Rochkind

    Roedy Green Guest

    On Mon, 7 Jul 2003 13:16:18 -0500, "Dale King" <>
    wrote or quoted :

    >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.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Jul 12, 2003
    #16
  17. Marc Rochkind

    Dale King Guest

    "Roedy Green" <> wrote in message
    news:...
    > On Mon, 7 Jul 2003 13:16:18 -0500, "Dale King" <>
    > wrote or quoted :
    >
    > >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.



    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
    Dale King, Jul 14, 2003
    #17
  18. Marc Rochkind

    Dale King Guest

    "steve_H" <> wrote in message
    news:...
    > Roedy Green <> wrote in message

    news:<>...
    > > On Mon, 7 Jul 2003 13:16:18 -0500, "Dale King" <>
    > > wrote or quoted :
    > >
    > > >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.

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


    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.

    --
    Dale King
    Dale King, Jul 14, 2003
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Schnoffos
    Replies:
    2
    Views:
    1,212
    Martien Verbruggen
    Jun 27, 2003
  2. Hal Styli
    Replies:
    14
    Views:
    1,634
    Old Wolf
    Jan 20, 2004
  3. n00m
    Replies:
    5
    Views:
    396
  4. Replies:
    7
    Views:
    176
  5. Replies:
    21
    Views:
    300
    Barry Schwarz
    Mar 5, 2014
Loading...

Share This Page