C to Java migration - how to cope with passing by value only?

[opalpa]

Yes... I cannot see the point in distinction between

primitive types and objects,

Something java 1.5 tries to hide some with "boxing" -- automatic
conversion between int and Integer and similarly for other primitive to
corresponding java.lang classes. I dunno for sure, perhaps original
int was in place because making Integer instance for ints was
intolebrly slow on then existing generally available technology?

and I can see some inconsistency in the fact that you can modify an
object passed to the function, but you cannot replace the object
completely...

You can provide routines which modify carefully considered comprising
pieces, in the original example you can use Color's and JButton's
settors. There is a problem if originally there was no instance but
that's not replacing right?

Woebegone's ColorButton example is an enapsulation that I'd use in file
scope. For further reaching functions I'd first research alternate
designs because I've never used this pattern outside a file scope.
Java indeed limits expressions and I believe that these limits have
lead to me using others code more frequently then I could C++ because I
can read and start using Java code faster.

but... well... I see this as a part of the game... I like Java
anyway .

Here is extension of the idea: String, BigDecimal and many other
libraries are immutable, not only can the called function not evicerate
an instance but it cannot even modify a particular represented value in
anyway. This quality makes it easier to contemplate properties of
extensive systems.

 

[Dobieslaw Wroblewski]

void (A& a) {

The above code does not compile, it should be:

void f(A& a) {
A aa;
a = aa;

}

My C++ is rusty (cause of wonderful .... you know it's coming ...
Java). I believe the second snippet creates an A on the stack and
assigning aa to a does not prevent destructor of aa destorying the
instance which is therefor useless when refered to after function
finish.

The second snippet:
1. creates aa (of type A) on the stack,
2. makes a field-by-field literal memcopy of all fields of aa to all fields
of a, OR...
2a. if '=' operator is defined for A class with an argument A, this operator
is performed on a,
3. aa's destructor is called (provided A is a class) when returning from the
function.

The first snipped assigns a pointer (that's what new returns in C++,
right?) to a reference which does not work (right?).

This is simply a bad syntax. 'new' returns a pointer, i.e. A*, not A&. A*
and A& are not syntactically compatible (although their semantics is the
same).
A& is syntactically compatible with A and *(A*). Some people do not like
references in C++, because their syntax is a bit inconsistent with semantics
(syntactically you use them as the original types, while semantically they
are pointers). Anyway, using references in C++ makes a code nicer to read
(not so many $%^&* and sometimes easier to write.

DW.

 

[Dobieslaw Wroblewski]

Do you suggest that the creators of Java decided to keep primitive types
because of performance (speed/memory) reasons?

DW.

 

[Aquila Deus]

Hi,

Yesterday I tried to write something like (it's not the exact code):

void Foo(Color cl, JButton bn) {
cl = new Color(200, 200, 200);
bn = new JButton("Button");
bn.setbackground(cl);
}

And to my amazement - it did not work as I expected. Then I read in the
tutorial that the references to classes are passed by value in Java...
because everything is passed by value in fact ;-).

I was previously programming mainly in C++ and used passing arguments by
reference or by pointer quite often. Are there any well established
strategies of how to change the way of thinking (this is probably easier ;-)
and how to port the C++ code so that it uses passing by value only? I can
think of passing Object[] to functions like Foo, but this does not seem very
elegant...

Passing by value is a mistake, because you should see every object not
created in your own method as an interface to the real object, rather
than the real object itself. And then, you should never pass by value
since you don't really know an interface's value

 

[Dimitri Maziuk]

Dobieslaw Wroblewski sez:

Do you suggest that the creators of Java decided to keep primitive types
because of performance (speed/memory) reasons?

Considering that Java was originally intended for programming
VCRs and microwave ovens, I doubt it (how much performance
does a VCR program need?) You'll have to ask Gosling why
Java takes the OO principle "user-defined types are first-class
citizens" to a whole new level: "primitive types are second-rate".
Who knows what they were thinking.

Dima

 

[Chris Smith]

I was previously programming mainly in C++ and used passing arguments by
reference or by pointer quite often. Are there any well established
strategies of how to change the way of thinking (this is probably easier ;-)
and how to port the C++ code so that it uses passing by value only? I can
think of passing Object[] to functions like Foo, but this does not seem very
elegant...

There's an article I wrote on this at http://jinx.swiki.net/ -- but as
of right now, I can't get to that site, so I'll summarize. Here are
some things to keep in mind:

1. Fundamentally, the return value of an object specifies its output,
and the parameters its input. That distinction is enforced more in Java
than other languages. You should understand and stick to it as much as
possible. (This should not, though, be interpreted so as to exclude the
possibility of side effects of functions; Java is not a functional
language.)

2. Often the desire to use "out params" is motivated by the existence of
only one return value. Here's how you should deal with that:

- If a return value was an error code in another language, exceptions
are the right way to do this in Java.

- If the return values are related, encapsulation in an object may be
the way to go.

- If the return values are unrelated, then perhaps you should split the
method into two different methods, each returning its corresponding
result. This may involve moving the methods into a more short-lived
object so as to share intermediate results without re-entrancy issues.

The problematic part is choosing between the last two suboptions in #2.
The choice comes down to which choice yields the stronger abstractions.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

Passing by value is a mistake, because you should see every object not
created in your own method as an interface to the real object, rather
than the real object itself. And then, you should never pass by value
since you don't really know an interface's value

I'm not sure what you're trying to say; but you might consider finding
different terminology. Passing by value is an inherent characteristic
of the Java programming language. It's not up to the programmer at all;
if you write Java, and if you pass parameters at all in Java, then
you're passing by value simply because that's how the language works.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

Considering that Java was originally intended for programming
VCRs and microwave ovens, I doubt it (how much performance
does a VCR program need?) You'll have to ask Gosling why
Java takes the OO principle "user-defined types are first-class
citizens" to a whole new level: "primitive types are second-rate".
Who knows what they were thinking.

It's certainly about performance. I don't see how it could be
otherwise.

Incidentally, performance is especially critical when programming for
embedded devices, both because they frequently have real-time
requirements and because the processors themselves are relatively
impoverished. If a one-time investment in better software can lower the
cost per device by $5 by choosing a cheaper CPU, then that's a huge win!

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Aquila Deus]

I'm not sure what you're trying to say; but you might consider finding
different terminology. Passing by value is an inherent characteristic
of the Java programming language. It's not up to the programmer at all;
if you write Java, and if you pass parameters at all in Java, then
you're passing by value simply because that's how the language works.

But why not remove it at all? For instance, use a Number class instead
of the primitive int and long. And the programmer doesn't need to know
whether the Number is actually implmented as a int, long, or a
BigInteger.

 

[Dobieslaw Wroblewski]

Thanks for the answer, I found the comment on exceptions very useful... I
really often used functions in C/C++ such a way that they returned an error
code, thus any other out-value had to be passed by reference.

DW.

 

[Brill2]

<snippit>
But why not remove it at all? For instance, use a Number class instead
of the primitive int and long. And the programmer doesn't need to know
whether the Number is actually implmented as a int, long, or a
BigInteger
</snippit>

Aquila, if you do this then how do you ever manage number memory? I
know lots of people will say that perhaps we don't need to do this
anymore because we have ample memory to work with but I don't think
it's the case. When you use an int in java you know that you are
getting 4 bytes. If you didn't know how much you were getting how
would you ever integrate with another application. What if that
application isn't written in java? You have to do a conversion because
of a proprietary data format?

For instance if you need to use a GUID in an application you need to
know how many bytes you are working with and what type of numbers you
want to store. The database application isn't simply going to abstract
that out for you.

You might be right that in certain ways you could abstract out
primitives in certain cases, maybe in a college class. But in the real
world I just can't see this happening.

 

[Chris Smith]

But why not remove it at all? For instance, use a Number class instead
of the primitive int and long. And the programmer doesn't need to know
whether the Number is actually implmented as a int, long, or a
BigInteger.

Are you changing the subject? If so, just a quick heads-up note to that
effect would clarify things a bit. Otherwise, what does this have to do
with passing by reference or value? You can use the Number class if you
like -- although using it constantly for all numeric parameters would be
a very bad idea -- but that doesn't change the fact that you're passing
that parameter by value, not by reference. Again: all parameter passing
in Java is by value.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Dimitri Maziuk]

Dobieslaw Wroblewski sez:

Thanks for the answer, I found the comment on exceptions very useful... I
really often used functions in C/C++ such a way that they returned an error
code, thus any other out-value had to be passed by reference.

Keep in mind, however, that exceptions come with an overhead.
If performance is a concern you really don't want to throw an
exception for a recoverable error that you expect to come up
often.

Dima

 

[Chris Smith]

Keep in mind, however, that exceptions come with an overhead.
If performance is a concern you really don't want to throw an
exception for a recoverable error that you expect to come up
often.

Depends on your definition of "often". An exception that occurs once
per second, for example, is going to have practically no performance
impact at all. If your "exception" is happening more like 100 times per
second, then you may well start to see a performance impact. At that
point, you should stop calling it an "exception", and start calling it a
"rule".

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Aquila Deus]

Are you changing the subject?
Yep.

If so, just a quick heads-up note to that
effect would clarify things a bit. Otherwise, what does this have to do
with passing by reference or value? You can use the Number class if you
like -- although using it constantly for all numeric parameters would be
a very bad idea -- but that doesn't change the fact that you're passing
that parameter by value, not by reference. Again: all parameter passing
in Java is by value.

You mean the "reference value"?

I don't think the Number would be slow, the JIT compiler can replace it
with int/long and change it to BigInteger when overflow (if overflow
can trigger a trap). Some systems such as Common Lisp and Scheme
implement number in similiar way and their speed doesn't suffer.

 

[Chris Uppal]

You might be right that in certain ways you could abstract out
primitives in certain cases, maybe in a college class. But in the real
world I just can't see this happening.

In point of fact this is perfectly doable. The techniques needed have been
well-understood since long before Java was invented. They do cause a small
runtime hit, but compared with the inflexibility (indeed fragility) of
"primitive types", that hit is well worthwhile (IMO). I feel that one of the
original mistakes (a premature optimisation, in fact) in the Java design was to
use primitive types as the /default/ representation of integers, etc. If
instead the choice had been to use real, flexible, objects as the default
representation (with machine-oriented 32/64 etc bit representations available
as an /optimisation/ for skilled programmers) then the Java world would be
better off in many ways.

-- chris