On Aug 18, 2014, at 2:25 PM, Daniel Sank <[email protected]> wrote:
> It's just like the case of a GUI and a business logic object. The GUI > probably gets a reference to the business logic object so that eg. button > pushes can invoke methods on the object. However, that reference should > probably be weak so that the business logic object can be garbage collected > when it's finished with its business. There's no sense (to me) in keeping an > object alive because a GUI, logger, or other observer is observing it. Am I > just wrong? When it comes to GUI toolkits, there are two philosophies on this. One, embodied in toolkits like OS X's Cocoa and (if you squint at it just right) Qt, is that this reference should always be weak (or, you know, __unsafe __unretained which is like "weak" with a bit of a speech impediment) because something else (a window management layer, for example, or a data-access layer updating some data) will probably be holding the reference. This is popular in C-style toolkits with an object model and reference counting because there's often an implicit circular reference between a view and its controller, and cleaning that up in C or C++ can be messy. Another, embodied in toolkits like GTK+ and the JavaScript DOM, is that this reference should always be strong, because the GUI can logically manipulate the model object it refers to, and so it should have a strong reference - otherwise GUI actions might spontaneously start causing crashes when something unrelated forgets about that object. I am a big fan of the latter style. Although there is often something to hold that strong reference, sometimes there is actually nothing else to hold it, and so you have to create bizarre lifecycle shenanigans to replicate the fairly straightforward behavior of "the user's eyeballs are looking at the screen, there's a window on the screen, the window refers to my model object, therefore the user's eyeballs have a strong reference to my model object". Some things that present GUIs are observers, some things are manipulators; the former model works for observers, the latter model works well for both. So I'm inclined to say you're wrong. However, according to the efficient-market hypothesis, Cocoa must be better than any of those other things, so I may be in a minority there. Nevertheless in PB the distinction is even more stark: if your example is that you have a model object with a GUI observer, it is the GUI that would expose the Referenceable, because the model would need to call methods on the view to update it. So this isn't about whether your model stays memory-resident while the GUI is up, but rather, whether the GUI itself stays memory-resident while the model is alive! Obviously you wouldn't want your GUI or your logger to disappear while the model is still active. -glyph
_______________________________________________ Twisted-Python mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
