Thanks for the suggestions. I decided to go with having the handler
object retain itself and release itself when the interaction is
completed. That avoids having to have more instance variables in the
document object to track handlers and release them when done.
Also, thanks for the pointers
Hi!
In the document object, I am observing such an event, then creating a handler
and calling it. I have handled creation either by explicit allocation such as
[[HandlerClass alloc] initWith...] or by writing a class method to create an
object like [HandlerClass createHandlerWith...]. I
On Jul 17, 2011, at 10:32 PM, John Brownie wrote:
[HandlerClass createHandlerWith...]
I think your model is correct, but Cocoa convention is that method names
beginning with create confer ownership to the caller. If the caller does not
need to release the object, the method name should not be
On Jul 18, 2011, at 8:18 AM, Scott Ribe wrote:
On Jul 17, 2011, at 10:32 PM, John Brownie wrote:
[HandlerClass createHandlerWith...]
I think your model is correct, but Cocoa convention is that method names
beginning with create confer ownership to the caller. If the caller does not
I'm a relative newcomer to Cocoa, and I'm rewriting my Carbon-based
application in Cocoa, taking the opportunity to refactor and improve the
structure of my code.
One area is giving me some difficulty in working out what is
appropriate. The basic idea is to split off the handling of a
On Jul 17, 2011, at 9:32 PM, John Brownie wrote:
In the document object, I am observing such an event, then creating a handler
and calling it. I have handled creation either by explicit allocation such as
[[HandlerClass alloc] initWith...] or by writing a class method to create an
object
