stupid question

B

bob

Hi.

I was just wondering if a java function is able to modify variables
that are passed to it.

I want to create a function that I can pass 3 x, y, and z variables to
and have the function set them to a certain point. Does anyone know
how to do this?
 
A

Andrew McDonagh

Hi.

I was just wondering if a java function is able to modify variables
that are passed to it.

I want to create a function that I can pass 3 x, y, and z variables to
and have the function set them to a certain point. Does anyone know
how to do this?

in order to help you....

what type are x, y & z?

what do you mean by 'set them to a certain point"?
 
S

Simon Shearn

Hi.

I was just wondering if a java function is able to modify variables
that are passed to it.

I want to create a function that I can pass 3 x, y, and z variables to
and have the function set them to a certain point. Does anyone know
how to do this?

Hello -

Assuming that x, y and z are primitive types such as int or float, and your
method signature is something like
public void setPoint(int x, int y, int z)
then they will be passed by value to your method, and changes will not be
returned to the calling code.

A common approach to this task is to create a class called Point which
encapsulates the x,y,z values, and pass an instance of the class to your
method, eg.
public void setPoint(Point p)
p is a reference type, so changes made to it would be passed back to the
calling code.

Regards,

Simon
 
A

Aquila Deus

Andrew said:
in order to help you....

what type are x, y & z?

what do you mean by 'set them to a certain point"?

I guess his x,y,z refers to one point in 3D space.

Actually he himself has told the answer - Use a Point!
public class Point {public double x; public double y; public double z;}
 
B

bob

If possible, I'd rather not write my own class, and the existing Point
class is only for a 2d point (with x and y, no z).




Aquila said:
variables

I guess his x,y,z refers to one point in 3D space.

Actually he himself has told the answer - Use a Point!
public class Point {public double x; public double y; public double
z;}
 
S

Steve Green

If possible, I'd rather not write my own class, and the existing Point
class is only for a 2d point (with x and y, no z).





z;}

Java3D has a 3d Point in one of the packages.
I have not played with it for a while and don't remeber where it is off
hand. Java3D might be overkill for what you want though.

--Steve
 
T

Tony Morris

Hi.

I was just wondering if a java function is able to modify variables
that are passed to it.

I want to create a function that I can pass 3 x, y, and z variables to
and have the function set them to a certain point. Does anyone know
how to do this?

No, you cannot pass variables and have changes to those variables reflected
in the caller.
You can however, pass a reference type variable (which is copied) to the
method, dereference it and modify the referred instance.
This change will be reflected through the caller's reference.
http://qa.jtiger.org/GetQAndA.action?qids=37&showAnswers=true

All of this is beside the point that it's an incredibly nasty thing to do.

--
Tony Morris

JTiger Unit Test Framework for J2SE 1.5
http://www.jtiger.org/
Java Q&A (FAQ, Trivia)
http://qa.jtiger.org/
http://xdweb.net/~dibblego/
 
J

jonck

All of this is beside the point that it's an incredibly nasty thing
to do.

Why do you think so? It's very common to do this, in fact it's done
very often in the Java API itself. Take for example just about every
method in the Collections class.
 
T

Tony Morris

jonck said:
to do.

Why do you think so? It's very common to do this, in fact it's done
very often in the Java API itself. Take for example just about every
method in the Collections class.

The core API is very poorly designed; I think this is the general consensus,
or at least, it is for those that I know in my workplace, etc.
I think it's also generally considered poor form to mute any object that is
passed with the intention of the caller using the change in some way, so I
won't bother undermining the other documents out there that make it quite
clear what the reasoning behind it is.

On a less "generally accepted" note, I follow the rules of "Design By
Contract" and I exercise "Test Driven Development". Through using these
techniques, it has become more apparant (it was previously speculative) that
passing or returning *any* mutable type is a nasty thing to do. But, of
course, this one will take a while to catch on, so proving it is a little
more difficult.

If you have no luck finding material, I'll have a look around myself.

--
Tony Morris

JTiger Unit Test Framework for J2SE 1.5
http://www.jtiger.org/
Java Q&A (FAQ, Trivia)
http://qa.jtiger.org/
http://xdweb.net/~dibblego/
 
J

Jonck

The core API is very poorly designed; I think this is the general
consensus, or at least, it is for those that I know in my workplace,
etc. I think it's also generally considered poor form to mute any
object that is passed with the intention of the caller using the
change in some way, so I won't bother undermining the other documents
out there that make it quite clear what the reasoning behind it is.

I agree that in general a method is clearer when a method does not alter
the passed arguments. But in my experience it's hard to avoid in some
cases.
For example, the Collections.sort method. How would you have implemented
this instead? By creating a copy of the passed List, sorting the copy
and returning that as the sorted list?

Regards, Jonck
 
A

Antti S. Brax

For example, the Collections.sort method. How would you have implemented
this instead? By creating a copy of the passed List, sorting the copy
and returning that as the sorted list?

The java.util.Collections class is just a one example. In fact,
if you count every method in the core API you'll find that only
a tiny fraction of the methods modify their parameters. So it is
in fact not at all common in the Java core API.
 
A

Aquila Deus

Jonck said:
I agree that in general a method is clearer when a method does not alter
the passed arguments. But in my experience it's hard to avoid in some
cases.
For example, the Collections.sort method. How would you have implemented
this instead? By creating a copy of the passed List, sorting the copy
and returning that as the sorted list?

That's how most functional languages (such as ML) do sort, though
internally it's probably not.
 
P

P.Hill

Tony said:
On a less "generally accepted" note, I follow the rules of "Design By
Contract" and I exercise "Test Driven Development". Through using these
techniques, it has become more apparant (it was previously speculative) that
passing or returning *any* mutable type is a nasty thing to do. But, of
course, this one will take a while to catch on, so proving it is a little
more difficult.

Please, don't sign me up for this extreme orthodoxy.
A collection that is not mutable? That's obsurd!

-Paul
 
A

Andrew McDonagh

P.Hill said:
Please, don't sign me up for this extreme orthodoxy.
A collection that is not mutable? That's obsurd!

-Paul

Actually its not.

A very good technique for creating very efficient and thread safe
listener list is to use immutable objects.

Essentially every time a new listener is added or removed, we create a
new list of listeners - we don't modify the existing list.

See...

http://www.javaworld.com/javaworld/jw-03-1999/jw-03-toolbox.html
 
A

Aquila Deus

P.Hill said:
Please, don't sign me up for this extreme orthodoxy.
A collection that is not mutable? That's obsurd!

A list in ML is just immutable. It works, and faster than java (ocaml's
performance apporachs to optimized c/c++ apps). But it doesn't really
have to be immutable internally :)
 
P

P.Hill

Andrew said:
Actually its not.

A very good technique for creating very efficient and thread safe
listener list is to use immutable objects.

And who said I want to have the overhead of thread safe on every
data structure I ever build?
Essentially every time a new listener is added or removed, we create a
new list of listeners - we don't modify the existing list.

Sounds like it probably would be an excellent application of such a
construct, not an argument for generally *no* immutable objects. I'll
stick with the adjective absurd when applied to "*any* immutable object"
as stated by Tony. This is opposed to a design rule along the lines of:
consider a design which would eliminate all or nearly all mutable objects.

For example, in the above example, if there were 100s of listeners and
some were always coming and going you wouldn't want to impose the "no"
imutable rule. Unusual? Sure, but Tony wanted a universal rule, not a
nearly always a good idea rule.

The referenced article is about objects used in multiple threads, not
whether such a pattern is a good idea in *all* cases.

To me the rule seems like the idea that all conditional logic can be
eliminated and replaced by polymorphism, but we don't eliminate all
conditional logic do we?

*Never* over-generalize, or I'll *always* get on your case :)

-Paul
 
A

Andrew McDonagh

P.Hill said:
And who said I want to have the overhead of thread safe on every
data structure I ever build?

With the example, there is no over head for thread safety, its intrinsic
to the nature of immutable objects. There's also no difference in
performance overhead in creating a new list of listeners, than if we
simply added/removed from a conventional arrayList. Its arguable that
there will in fact be a performance gain, as the internal buffer used by
the ArrayList does not exist in the immutable list - and therefore
nothing requiring resizing.
Sounds like it probably would be an excellent application of such a
construct, not an argument for generally *no* immutable objects.

I didn't offer it as a general replacement, but simply as an example
that we can have immutable collections.
I'll stick with the adjective absurd when applied to "*any* immutable object"
as stated by Tony. This is opposed to a design rule along the lines of:
consider a design which would eliminate all or nearly all mutable objects.

For example, in the above example, if there were 100s of listeners and
some were always coming and going you wouldn't want to impose the "no"
imutable rule. Unusual? Sure, but Tony wanted a universal rule, not a
nearly always a good idea rule.



The referenced article is about objects used in multiple threads, not
whether such a pattern is a good idea in *all* cases.

Yes the article is focused on threads, however, immutable objects are by
their nature, thread safe.

Personally I can NOT see a situation where every object in our
applications are immutable - does that mean its not possible or not
worthy or a failing on my part?

I don't know. I do know that as we learn more, we'll find better ways
of using these constructs we have today in ever more inventive ways.
Objects when first pioneered were crudely used compared to how we use
them today, and in 5 years time, they'll be saying the same about our
use of objects.
To me the rule seems like the idea that all conditional logic can be
eliminated and replaced by polymorphism, but we don't eliminate all
conditional logic do we?

Why not? Is it because we can't or don't want too?

I personally strive for polymorphism over conditional, using the
appropriate COmmand, Strategy, Visitor patterns as appropriate. Whilst
some people might find the resulting design harder to 'read' in a single
pass. Others find it easier to use and extend in a safe manner.
*Never* over-generalize, or I'll *always* get on your case :)

-Paul

I didn't, but I think you are tending too. :)
 
T

Tony Morris

P.Hill said:
And who said I want to have the overhead of thread safe on every
data structure I ever build?


Sounds like it probably would be an excellent application of such a
construct, not an argument for generally *no* immutable objects. I'll
stick with the adjective absurd when applied to "*any* immutable object"
as stated by Tony. This is opposed to a design rule along the lines of:
consider a design which would eliminate all or nearly all mutable objects.

For example, in the above example, if there were 100s of listeners and
some were always coming and going you wouldn't want to impose the "no"
imutable rule. Unusual? Sure, but Tony wanted a universal rule, not a
nearly always a good idea rule.


The referenced article is about objects used in multiple threads, not
whether such a pattern is a good idea in *all* cases.

To me the rule seems like the idea that all conditional logic can be
eliminated and replaced by polymorphism, but we don't eliminate all
conditional logic do we?

*Never* over-generalize, or I'll *always* get on your case :)

-Paul

Passing or returning a mutable type can always be done better.
The emphasis here being the term 'always'.
Feel free to challenge that assertion, but I beg of you to think about it
for a while first.

--
Tony Morris

JTiger Unit Test Framework for J2SE 1.5
http://www.jtiger.org/
Java Q&A (FAQ, Trivia)
http://qa.jtiger.org/
http://xdweb.net/~dibblego/
 
P

P.Hill

Andrew said:
I didn't offer it as a general replacement, but simply as an example
that we can have immutable collections.

No, but Tony did and I thought I made that clear, for example when I said:
Why not? Is it because we can't or don't want too?

Because it would be absurd to apply it 100% of the time.
Every if statement might require another variation in
class definitions. Multiple that by all the variations
in your code and you might end up with an impossible number
of classes.
 
A

Andrew McDonagh

P.Hill said:
No, but Tony did and I thought I made that clear, for example when I said:



Because it would be absurd to apply it 100% of the time.
Every if statement might require another variation in
class definitions. Multiple that by all the variations
in your code and you might end up with an impossible number
of classes.

Why would it be an impossible number of classes - wouldn't we have the
same number of classes as we did IFs?

It may come down to: many small (tiny) classes or few larger classes.

YMMV - but I personally favour many smaller classes - they help reduce
duplication, are easier to test stand alone and provide more flexible
re-use.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top