get vs set
Hi guys, wondering about the title heh?
Well, I have been wondering about what would be the best way to access global variable.
Let's take for instance the case of a multi editor IDE like Eclipse.
an action occurs which is supposed to do some work on the current Editor. How does the action get a reference to the currently active editor?
2 ways: get or set.
get:
you actively get the reference with some kind of mechanism. (for example a variable singleton)
pros: minimal space (one reference), editor change takes O(1) in time,
cons: a fetch every time the variable is used, need for a supplying mechanism(singleton )
Danger that developer mis-read the specification and creates a local copy received by the "get" mechanism. (if anyone remember my post about destroying object /setting an object to null see http://forum.java.sun.com/thread.jsp?forum=31&thread=470148 )
set :
the reference is there. no other worries
pros: direct use possible
cons: space O(n), editor change O(n); n = number of users for editors
Event channel like mechanism to maintain the list of users and propagate editor changes.
Which one would you use?
I like "get" better.
NOTE: In Eclipse they are using "set"
[1304 byte] By [
Mordana] at [2007-9-30 0:41:49]
I'm sorry but I don't understand what you mean by getting the reference using a set.
You mean when an editor is activated, it finds the UI framework and sets this as the current editor, as opposed to the UI framework polling the editors to find which is the current one?
> You mean when an editor is activated, it finds the UI
> framework and sets this as the current editor,
> as opposed to the UI framework polling the editors to
> find which is the current one?
>
Yea, except the UI framework is not "polling", it just fetches the reference when it needs it.
It is two different ways of doing the same thing.
Quite an important design choice IMO.
> it just> fetches the reference when it needs it.How is that different from the get version?
> > it just
> > fetches the reference when it needs it.
>
> How is that different from the get version?
That's the version I'm talking about. It is your job to get the reference.
While with the "set" version, it is the responsability of someone else to give (or set) you the reference. You just have to store the reference in a class member for later use.
It depends on your objectives and how often the active dwg changes.
the set method is kind of like an observer and you may end up cycling through several receivers each time the active editor changes. Not a good idea because it can slow down if you do too many things that way. I prefer to give data only to those that immediately need it, especially when that data will change.
Also you should know eclipse will return null for certain editParts if the request is not inside the GUI thread. In this case, how would the set method work?
> It depends on your objectives and how often the active
> dwg changes.
>
> the set method is kind of like an observer and you may
> end up cycling through several receivers each time the
> active editor changes. Not a good idea because it can
> slow down if you do too many things that way. I
> prefer to give data only to those that immediately
> need it, especially when that data will change.
>
>
> Also you should know eclipse will return null for
> certain editParts if the request is not inside the GUI
> thread. In this case, how would the set method work?
I'm a real newb in programming eclipse, doing some learning right now. Actually that's why I came up with this post. Because in Eclipse, IActionDelegate classes use the "set" method, i.e they are feeded with selection changes.
Eclipse returns null for some EditorPart ? hmm I don't see. What I'm referring to is this:
http://help.eclipse.org/help20/content/help:/org.eclipse.platform.doc.isv/reference/api/org/eclipse/ui/IEditorActionDelegate.html
If IEditorPart is null, well you do the same thing as if you have to "get" IEditorPart yourself.
"Get" method would do something like
IEditorPart iep = ActiveEditorSupplier.getActiveEditor();
if(iep == null)
//do stuff
With the set method you only do
if(_currentEditor == null)
//do stuff
because you already have done
setActiveEditor(IAction action, IEditorPart targetEditor) {
_currentEditor = targetEditor;
}
Ah, I think I get it.
Everywhere you need a reference to an object, you can either have someone set the reference you will use, or you can use a singleton pattern and access a static method of a class.
I don't think there is a clear cut rule that says one is better than the other.
> Ah, I think I get it.
>
> Everywhere you need a reference to an object, you can
> either have someone set the reference you will use, or
> you can use a singleton pattern and access a static
> method of a class.
>
> I don't think there is a clear cut rule that says one
> is better than the other.
if you use the set method you need to be sure that everyone you 'set' this variable on will be interested in it, else you are wasting time and resources. the get method obviously will only be used by those who need it and only when necessary.
You could combine the two.
Use set to send out an ActiveEditorChanged event.
Then allow the receiver to use get if it so desires.
depends on your needs.
> if you use the set method you need to be sure that
> everyone you 'set' this variable on will be interested
> in it, else you are wasting time and resources. the
> get method obviously will only be used by those who
> need it and only when necessary.
>
> You could combine the two.
> Use set to send out an ActiveEditorChanged event.
> Then allow the receiver to use get if it so desires.
>
> depends on your needs.
I was going to say that the Observer-Observable pattern seems applicable. How can you possibly know all the references to an Object in a dynamic environment?
Observer-Observable : (well as i see it, this pattern behaves like an EventChannel )
yea that's for the set method (as i defined it)
The get method is not that. You just actively get a reference.
//How can you possibly know all the references to an Object in a dynamic environment?
I don't see your point
You can obviously use the two methods. Just that I find pretty annoying to have to implement/register listeners.
It is more neat to get the reference with a Singleton.
> //How can you possibly know all the references to an
> Object in a dynamic environment?
>
> I don't see your point
In an application like Eclipse, how can you know where all the references to a component are or even how many there are? The user may be running your code with umpteen other peoples code. How would you know that you have set all the references in memory?
Also, how can you keep people from putting references in places where you cannot reach them?
Personally, I prefer a solution where you do something like this:
public abstract class Example
{
private static final Example wrapper = new ExampleWrapper(new DefaultExample());
Example(){}
public static final getExample()
{
return wrapper;
}
static final setExample(Example example)
{
wrapper.setInstance(example);
}
public void doSomething();
private static class ExampleWrapper extends Example
{
private instance;
private ExampleWrapper(Example initial)
{
instance = example;
}
private synchronized setInstance(Example example)
{
instance = example;
}
public synchronized void doSomething()
{
instance.doSomething();
}
}
}
That way, it doesn't matter if the caller only needs to get the instance once. After that you can change the underlying reference seemlessly. The caller will not need a new reference.
> > //How can you possibly know all the references to
> an
> > Object in a dynamic environment?
> >
> > I don't see your point
>
> In an application like Eclipse, how can you know where
> all the references to a component are or even how many
> there are? The user may be running your code with
> umpteen other peoples code. How would you know that
> you have set all the references in memory?
Huh?
Why would a developer IDE be running in a context where other users are producing objects?
> Why would a developer IDE be running in a context
> where other users are producing objects?
I don't know what you mean. It clearly has nothing to do with what I wrote. I never said anything about other "other users are producing objects." I'm sure you've used Eclipse. You realize that there are hundreds of pligins available written by many differnt people and groups. As a developer of one of theose plugins, you cannot know what other plugins the user will add to their environment or how they are desinged.
> > Why would a developer IDE be running in a context
> > where other users are producing objects?
>
> I don't know what you mean. It clearly has nothing to
> do with what I wrote.
It was in response to what you wrote, but I was reading something that you weren't intending. Although I had to read the thread three more times to figure that out.
Although that now takes me back to the post that started that....
> > if you use the set method you need to be sure that
> > everyone you 'set' this variable on will be
> interested
> > in it, else you are wasting time and resources.
> the
> > get method obviously will only be used by those who
> > need it and only when necessary.
> >
> > You could combine the two.
> > Use set to send out an ActiveEditorChanged event.
> > Then allow the receiver to use get if it so
> desires.
> >
> > depends on your needs.
>
> I was going to say that the Observer-Observable
> pattern seems applicable. How can you possibly know
> all the references to an Object in a dynamic
> environment?
Huh?
If there is a set/get method then why should a developer concern themselves with someone that holds on to the reference. If that is really a concern then a proxy should be used in the first place. And if it isn't a concern then it is up to the user to correctly use set each time.
Right?
(Or did I miss something again?)
> Huh?
That's kind of the point I'm trying to get at with my posts. I'm not sure what the OP is saying makes sense.
> If there is a set/get method then why should a
> developer concern themselves with someone that holds
> on to the reference. If that is really a concern then
> a proxy should be used in the first place. And if it
> isn't a concern then it is up to the user to correctly
> use set each time.
>
> Right?
>
> (Or did I miss something again?)
The OP is saying that there are two ways to deal with a shared Object that can be swapped out, in this case it's a window, I believe. 1. Use a singleton and hope that everyone always calls the getInstance method and don't cache the reference. 2. 'Set' all current references to the shared Object when it is changed.
I don't understand how #2 is feasible in an application like eclipse. I don't think it's sensible even if you know where all the references are. If I'm missing something, please enlighten me. And obviously there is a 3rd option (best, IMO) as we have both stated.
>
> I don't understand how #2 is feasible in an
> application like eclipse. I don't think it's sensible
> even if you know where all the references are. If I'm
> missing something, please enlighten me. And obviously
> there is a 3rd option (best, IMO) as we have both
> stated.
Ok, now I get it.
Of course one way to do #2 is to use a proxy. That makes it very feasible.
> Ok, now I get it.
>
> Of course one way to do #2 is to use a proxy. That
> makes it very feasible.
With a proxy you are not going out and setting every reference. You change one reference that all the other references use. If the OP was describing a proxy, it was rather poor description.
the OP (original poster aka me I guess) was not describing a proxy.
Your solution (proxy) is an hybrid.
In Eclipse, you can sensbily use the "set" method. You just might have a lot of listeners for a given event.. In Eclipse that's what they are using, at least for the editor focus event.
I was just saying I prefer the get method, knowing I cannot cache the reference.
Well you cache for the duration of an algorithm, when it does make sense to work on the same copy during the whole algorithm.
The proxy method sounds like a lot of extra code though.
Cheers
> the OP (original poster aka me I guess) was not
> describing a proxy.
>
> Your solution (proxy) is an hybrid.
I guess. It's a standard design pattern.
> In Eclipse, you can sensbily use the "set" method. You
> just might have a lot of listeners for a given event..
> In Eclipse that's what they are using, at least for
> the editor focus event.
So the set uses the Observer-Observable pattern. Why didn't you say that when it was mentioned before?
> The proxy method sounds like a lot of extra code
> though.
I guess if the class has a lot of methods. However some code generation can resolve that easily. In addition, you can add an improvement to my example that uses a ReadWriteLock also.
> In Eclipse, you can sensbily use the "set" method. You
> just might have a lot of listeners for a given event..
> In Eclipse that's what they are using, at least for
> the editor focus event.
In addition, this would imply that the listeners 'get' the reference. The Observable just sends a message talling the listeners that they need to do a get.
Observer-Observable...
Man There are so many names for the same pattern; Publisher-Subscriber, EventChannel, MVC, O-O. etc
Basically, you are notified of changes, provided you registered yourself with the Publisher, Obserbable or whatever. That's the "set", you are "set" the reference, externally.
> Basically, you are notified of changes, provided you
> registered yourself with the Publisher, Obserbable or
> whatever. That's the "set", you are "set" the
> reference, externally.
OK, sratch what I said. I see how that's a set. I though you meant that the code goes out and directly updates the references. I think it depends on the situation as to which you use.
One thing to note is that with the event version, the implementors can still mess up and not update the reference correctly. The proxy is basically impossible to screw up. They can't get at the actual reference in order to cache it.
The only flaw with the proxy version is that it does not "tell" the users of the object that the object has
changed. Whether this is an important consideration depends, of course, on what you want to achieve.
I have found it to be an elegant solution in many, if not most, situations as it makes object changes as
transparent as is possible. Sometimes, however, you do need to be "told" that an event has occured.
matfud
> I have found it to be an elegant solution in many, if> not most, situations as it makes object changes as > transparent as is possible. Sometimes, however, you do> need to be "told" that an event has occured.Absolutely. Good point.
I think that will sum up:set = possible implementator screw upget = possible user screw upproxy= overdose of transparency ;)up to you now!
Bah, how can you be talking about implementation details when you have not fully described the environment!?
each technique has its uses. One is not better than the other, but just different.
Is your program event driven? Are you in a multithreaded environment? How is this reference intended to be used?
I don't see the purpose of a proxy. IF the user is supposed to be able to use the object, then why give him a proxy, give him the object. Else, he will try to get the object from the proxy, and not be able too. If hes doing that, then there is something wrong with the design.
> I don't see the purpose of a proxy. IF the user is
> supposed to be able to use the object, then why give
> him a proxy, give him the object. Else, he will try
> to get the object from the proxy, and not be able too.
> If hes doing that, then there is something wrong with
> the design.
That's the whole point of the proxy. We don't want the client to have a reference to the Object and as far as the client knows the proxy is the Object. The purpose is that it allows the underlying Object to be replaced transparently.
