Thanks for the help guys, I agree, the way I had been thinking about it seemed like a strange way to go about dealing with the problem I was having. While this has started an interesting topic on NSProxy (seems like a really helpful class for implementing that pattern), I think my problem is going to require retooling my model rather than having a proxy be a stand-in for the object itself. Although I didn't make it very clear in my original post, what I am attempting to do is ensure that all objects in my model stay in sync. If I make the analogy to iTunes, I'm trying to create playlists for my main Library, yet if I make a change to said library (in this case swapping out a song entirely for it's updated version) all of the playlists that contain that song need to understand that it is the same song and not a new one. I think what may be called for is a way to update my objects in place so that all of the references to them throughout the rest of the model (playlists and whatnot, from the example) point to the updated object. If anyone has advice, I'd love to hear it.
On Mon, Dec 22, 2008 at 8:10 PM, WT <jrca...@gmail.com> wrote: > On Dec 23, 2008, at 1:55 AM, Mike Abdullah wrote: >> >> On 23 Dec 2008, at 00:30, WT wrote: >>> >>> On Dec 23, 2008, at 1:04 AM, Kyle Sluder wrote: >>>> >>>> On Mon, Dec 22, 2008 at 6:03 PM, WT <jrca...@gmail.com> wrote: >>>>> >>>>>> Of course, >>>>>> the proxy object's class has to share the same interface as the class >>>>>> of the >>>>>> objects it represents so that your code doesn't need to know whether >>>>>> it's >>>>>> dealing with a proxy or with the real thing. >>>>>> >>>>> >>>>> This isn't true in Objective-C. Take a look at NSProxy, the canonical >>>>> implementation of the very pattern you're describing. To state this >>>>> is to completely miss the characteristics that define Objective-C. >>>>> >>>> >>>> One is not obligated to use NSProxy to implement the Proxy pattern. I >>>> must admit not being all that familiar with NSProxy, but having the proxy >>>> and the object it stands for share the same public API (by being instances >>>> of subclasses of the same abstract class) seems to me to be a good thing >>>> since the object and its proxy can be transparently swapped in code. If I >>>> understand NSProxy correctly, you lose that transparency when you use it, >>>> because NSProxy and NSObject are in different inheritance trees. >>>> >>> >> No, the whole point is that although the proxy descends from a different >> hierarchy, no-one outside the proxy need know this. All other code treats it >> as though it were a non-proxy object of the expected class. Whenever one of >> the class's methods gets called, the proxy object receives a >> -methodSignatureForSelector: call, followed by -forwardInvocation: >> >> This saves you having to re-implement and keep up-to-date the entire API >> of your custom class from within the proxy. >> > > Ahh... ok. I see the value in NSProxy now. And I now also understand more > clearly what Kyle meant by "missing the characteristics that define Obj-C". > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/absolutcl%40gmail.com > > This email sent to absolu...@gmail.com > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
