GLC/GLO Pattern - static accessor to get/peek

Networking & Multiplayer
#1

Ok, little more awake now (was getting pretty tired last night/this morning) - this may or may not make more sense…

As I said in another post I have a central listener recording channel join/leave requests (UserHandler). I wanted to proxy this request on to an Arena (so that they can tell when a user has joined/left them) so I want to call userJoined() on my Arena GLO. However, I’m calling this from my UserHandler so I end up with either:


arenaRef.get(task).userJoined(somInfoHere)

or 

arenaRef.peek(task).userJoined(someInfoHere)

Right now, I use the get because I happen to know that hte userJoined method is going to want to write to the GLO. I’m not too keen on this because it means UserHandler has to have some implicit knowledge about whats going on in userJoined to know how to access the GLO. So, I was considering a pattern where I had static methods proxying inside Arena, something like


public static void userJoined(GLOReference<Arena> ref, SomeInfo somInfo) {
    SimTask task = SimTask.getCurrent();

    ref.get(task).userJoined(someInfo);
}

public void userJoined(SomeInfo someInfo) {
    // do real work here
}

Since this at least leaves me with the knowledge about whether userJoined needs to get or peek in one place it seems better, but I can remember seeing static proxy style thing shown as an Anti-Pattern.

I could have of course added the Arena itself as a listener in this particular case, but thats not true in all cases. So, I suspecet I’ve missed something along the way (brain?) but I was wondering if this the right way to do things or if theres a nicer pattern or if I’ve just made a big mistake somewhere…

Sorry if this is all getting a bit spammy now, I’ve only got a couple more questions… honest

Kev

#2

SimTask.accessCheck() doe sa run-time check to make sure that a method has been called with its gLo in the access strate itexpects. I use it extensively in PDTimer as an example.

This shoudl be fine. Wher it gets hairy is in contrcutors because Java states that yo ushoudl NOT use a “this” parameter inside of a constructor. This rather complicates static constructors.

Static fields must also be avoided. But static methods otherwise are fine.