tags:

views:

189

answers:

8

Hello!

Sorry for the stupid question.

I'm very sure, that the Java API provides a class which wraps a reference, and provides a getter and a setter to it.

class SomeWrapperClass<T> {
    private T obj;

    public T get(){ return obj; }

    public void set(T obj){ this.obj=obj; }
}

Am I right? Is there something like this in the Java API?

Thank you.

Yes, I could write it y myself, but why should I mimic existing functionality?

EDIT: I wanted to use it for reference parameters (like the ref keyword in C#), or more specific, to be able to "write to method parameters" ;)

A: 

there is java.lang.ref.Reference, but it is immutable (setter is missing). The java.lang.ref documentation says:

Every reference object provides methods for getting and clearing the reference. Aside from the clearing operation reference objects are otherwise immutable, so no set operation is provided. A program may further subclass these subclasses, adding whatever fields and methods are required for its purposes, or it may use these subclasses without change.

EDIT

void refDemo(MyReference<String> changeMe) {
   changeMe.set("I like changing!");
   ...

the caller:

String iWantToChange = "I'm like a woman";
Reference<String> ref = new MyReference<String>(iWantToChange)
refDemo(myRef);
ref.get();

I don't like it however, too much code. This kind of features must be supported at language level as in C#.

dfa
A: 

... good question, but have not come across it. I'd vote no.

.... hm, after some reflection, reflection might be what comes close to it: http://java.sun.com/developer/technicalArticles/ALT/Reflection/

vector
no pun intended ;-)
vector
how you want to use reflection here?
dfa
+6  A: 

There is the AtomicReference class, which provides this. It exists mostly to ensure atomicity, especially with the getAndSet() and compareAndSet() methods, but I guess it does what you want.

Avi
Are it's functions slower than writing non-atomic functions?
Liran Orevi
They are bound to be a bit slower as they are by definition thread safe, and thus need some form of synchronization.
extraneon
Though in the context of setting them once, for method parameters, I can hardly imagine that this could possibly make a noticeable difference. It would definitely be premature optimization to write your own for this reason. Clarity might be a better reason - you don't want an AtomicReference, you want a Reference.
Avi
A: 

I'm not clear what this would be for, but you could use one of the subclasses of the Reference type. They set the reference in the constructor rather than setter.

It' worth pointing out that the Reference subclasses are primarily intended to facilitate garbage collection, for example when used in conjunction with WeakHashMap.

Rich Seller
@Rich: yes you could. But those subclasses have specific semantics (and associated overheads) that make them the wrong answer here.
Stephen C
@Stephen That's pretty much what I say in the second paragraph isn't it?
Rich Seller
@Rich. I don't think so. That is not what your words say, or (IMO) even what they imply.
Stephen C
"primarily intended to facilitate garbage collection" addresses the specific semantics doesn't it?
Rich Seller
@Rich. No it doesn't. All it says is that the classes were designed for a different task. It does not say that they are wrong for this task.
Stephen C
A: 

I'm tempted to ask why you'd want one of these, but I assume it's so you can return multiple objects from a function...

Whenever I've wanted to do that, I've used an array or a container object...

bool doStuff(int params, ... , SomeObject[] returnedObject)
{
    returnedObject[0] = new SomeObject();
    return true;
}

void main(String[] args)
{
    SomeObject myObject;
    SomeObject[1] myObjectRef = new SomeObject[1];
    if(doStuff(..., myObjectRef))
    {
        myObject = myObjectRef[0];
        //handle stuff
    }
    //could not initialize.
}
Stobor
A: 

If you are trying to return multiple values from a function, I would create a Pair, Triple, &c class that acts like a tuple.

class Pair<A,B> {
A a;
B b;
public void Pair() { }
public void Pair(A a,B b) {
this.a=a;
this.b=b;
}
public void Pair( Pair<? extends A,? extends B> p) {
this.a=p.a;
this.b=p.b;
}
public void setFirst(A a) { this.a=a; }
public A getFirst() { return a; }
public void setSecond(B b) { this.b=b; }
public B getSecond() { return b; }
}

This would allow you to return 2 (techically infinite) return values

/* Reads a line from the provided input stream and returns the number of
 * characters read and the line read.*/
public Pair<Integer,String> read(System.in) {
...
}
KitsuneYMG
+1  A: 

When I started programming in Java after years of writing C++, I was concerned with the fact that I could not return multiple objects from a function.

It turned out that not only was it possible but it was also improving the design of my programs.

However, Java's implementation of CORBA uses single-element arrays to pass things by reference. This also works with basic types.

Maurice Perry
A: 

I think there is no Java API Class designed for your intent, i would also prefer your example (the Wrapper Class) then using this "array-trick" because you could insert later some guards or can check several thinks via aspects or reflection and you're able to add features which are cross-cutting-concerns functionality.

But be sure that's what you want to do! Maybe you could redesign and come to another solutions?

codedevour