Hi folks,
Hello again.
[snipped history]
One of the points made in the previous threads was that there should be no
need for sub-classes to have a link back to it's parent, and through the
correct splitting of functions (inter-instance in class, intra-instance
within container) I've done this okay.
Let's not say you should "never" have links back to the parent object. I've seen places where it made fine sense. I actually have I server I've been working on that does this. Individual connections keep a link to the main server, to inform it of changes in their status, based on network reads/writes and to access server wide functionality, like logging.
Generally though, what you say is a good rule of thumb.
My problem is now:
I need to be able to pass to the Trainset instance a ref to a callback within
Program (to refresh a PerlTk window, or to send a signal to a model railway
controller). This callback then needs to be triggered by the Trainset
instance itself, but also from Signals, Gantries, and Tcbs.
I should warn that I have no familiarity with TK, though I do have general GUI toolkit knowledge.
The above sounds backwards to me. Why should Trainset objects be tied to their interface? That limits their usefulness. The interface is an interface for representing Trainset objects, right? Well, then it makes sense for that interface to maintain a link to the Trainset object it is currently representing, right?
I assume TK is event driven. So, when an event happens, I would think you would access the Trainset in the event handler, make changes and update.
Now, if the Trainset object is somehow being modified by an outside source (the model controller you mention perhaps), things get a little trickier. You could always poll the Trainset object every so often to see if it has changed. Polling is generally considered bad though, so possibly better would be to have the code that is somehow changing Trainset, to call an update routine on the interface. If controller signals are just another event being handled by the interface and the interface is already keeping track of the Trainset, as I believe it should, the controller event handler can pass along the change and call for a refresh.
Be aware, if the GUI allows changing the Trainset and the model controller is changing the Trainset, you make have concurrent access issues to deal with.
Well, maybe that will give you some new ideas.
James
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>