If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

coping without pass-by-address/reference

I'm learning Java, and coming from a VB/C#/C++ background it's pretty straightforward for the most part.

The biggest thing I'm struggling with, though, is the apparent inability to alter parameters to functions. The classic example of this is swap, which you'd normally do in c++ with references, or perhaps addresses. But pointers (I appreciate they're not called that, but let's be honest, that's what they are) are passed by value in Java, so you can't switch them there. This also rules out a whole bunch of other functions I usually have to pass back stuff to the caller such as database connections, recordsets etc. I'd typically use the return value to signal success/failure, and if successful then the parameters could then be used. This is not only neat, but efficient, as you're just calling one function and getting a number of values in return.

What do you guys do in place of this ability? My work around has been to create small classes which contain the stuff I want populated and pass that around, but perhaps there's some way of looking at things in Java to work within this strange new world, not just to work around it. I appreciate each language is slightly different, even if they all have for..next, inheritance etc.

Re: coping without pass-by-address/reference

The basic Java approach is to pass in arguments and return the results as return values. Errors are handled by exceptions. It is possible to pass in objects and modify their contents, but, in general, good practice suggests that this is a less robust technique, being more error prone and less clear. Modifying the content of a method parameter is generally frowned on as a 'side-effect'.

In practice, null values are often returned in place of a valid object where an expected failure can occur (e.g. finding items in a collection), but conceptually these are null object returns rather than error indicators.

A method, like a class, should have a single clear task. If you want to return multiple objects from a method, you should be thinking about why - if the objects are closely related enough to be manipulated be a single method, why are they not part of a single object? and then shouldn't the method be called on the object of which they are a part?

If you want to populate an object with data, do it in the constructor, then call its methods to set the variable/optional data.

It's hard to be specific without some examples of the kind of thing that is causing you difficulty.

When the words are fuzzy, the programmers reflexively retreat to the most precise method of articulation available: source code. Although there is nothing more precise than code, there is also nothing more permanent or resistant to change. So the situation frequently crops up where nomenclature confusion drives programmers to begin coding prematurely, and that code becomes the de facto design, regardless of its appropriateness or correctness...
A. Cooper

Last edited by dlorde; August 12th, 2010 at 06:42 PM.

Please use &#91;CODE]...your code here...&#91;/CODE] tags when posting code. If you get an error, please post the full error message and stack trace, if present.