pete kirkham said:
Sometimes in Java you have similar constraints,
Only if you are dealing with a language that has those constraints.
For example the CORBA stuff has to deal with IDL that has out
parameters. But in general, I don't have to deal with the lack of
exceptions, not having objects.
so the best design in
such a situation is one that simulates pass by reference.
No, the best design is the one that provides the best abstraction for
the problem at hand. The result may be the same as just trying to
simulate pass by reference, but that is rare.
Discussing the
philosophy of software design without reference to the wider field of
computing is very blinkered.
I see no discussion of the wider field of computing on your part.
No, the other languages have a different set of constraints and
benefits, so that a 'proper design' and 'good practice' in C uses
different conventions to a 'proper design' in Java.
Those constraints are a lack of adequate abstractions to effectively
express a problem without resorting to giving up control of your
variables to another function.
Assembly language also has many coonstraints, and what is good
practice there is different than in Java. That does not mean I want to
see support for basic assembly level abstractions like unlimited goto.
By understanding these constraints you can learn when such conventions
are useful, and when they are not.
I understand these constraints and the convention of giving control of
your variables to another piece of code is not usefull.
In Java you can find that you are under similar constraints, for example
using a pool managed resource, or destructively sorting a list, so the
the appropriate design is one that mutates one of the parameters.
Which is not pass by reference, thus your faulty statement:
Saying
'any time you want the ability to pass by reference...your design is
poor' is a dogma that is often false in Java. If use wish to enforce it,
employ a pure functional language instead.
You are misreading pass-by-reference as modify an object referred to
by a parameter and it is not the same thing.
You left off two words from your quote of me that negate your claim of
dogma. It would help if you read what I actually said instead of what
you think I said. Here is what I said:
"I find any time you want the ability to pass by reference it is a red
flag
telling you that your design is poor."
That is a statement of personal experience. I have seen many, many
posts here about the lack of pass-by-reference and without fail it is
due to trying to continue a poor design created in another language
and usually indicates a non-OO mindset. I merely claim that it is my
experience that wanting the ability to pass-by-reference is an
indication that your design is flawed. And I have found that to be
true.
I do not say there cannot be a case where that is not true, but in my
experience it is true. If you want to show a case where
pass-by-reference would have been the best design choice, feel free.
So far you have talked in generalities.
I can certainly point to examples where the desire for
pass-by-reference truly is an indication of a poor design. For the
extreme example of a non-OO mindset in the pursuit of
pass-by-reference in Java, see this rather lengthy conversation I had
several years ago:
http://groups.google.com/[email protected]
Here is the original C function that Samuel Siren thought the height
of design:
void stat(int n, double x[], double y[], /* Do a lot of
stuff at */
double *mean_xp, double *mean_yp, /* the same time,
to */
double *var_xp, double *var_yp, /* increase
performance */
double *cov_xyp, double *cor_xyp,
double *ap, double *bp, double *cp)
That is 3 in parameters and 7 optional out parameters. He considered
Java useless because it would not allow him to do the same thing. Are
there any constraints that would make this a good design in Java? Not
as I see it.
