Hey! On 17/May/2010, at 8:26 PM, Mike Schrag wrote: > Well, sure you agree with them. And they're wrong too ;) LOL Ok, now it's time to break out the Nerf equipment! ;-)
> As far as I can tell, this API seems to be one that must have come from the > desktop version of EOF where you're always in-process to your changes. Those > API's are all dead to me. Yes, of course this design is from 'real' EOF! ObjC EOF and AppKit on NeXTSTEP/OPENSTEP! ;-) Dead or not, it's the history which forms what we have today. >> This is what I've used in the past (since ObjC days) and I don't know of a >> case where it fails. > This depends on your definition of "fail." I agree that for the way you're > using it it works. For the ACTUAL complaint I have, it seems insufficient. > I'm also not sure you even run in the right thread to throw that exception. > This responds to ObjectsChangedInStore, which probably means it runs in EC1's > thread? Or does it queue up and run in EC2's thread when in > performRecentChanges or something? Regardless, I suspect to make > inter-instance and intra-instance behavior match, you're going to have to do > a lot more work ... hence my gripe. Those two cases need to be different! If anything, the inter-instance case is broken in that it doesn't properly notify EC's in other running instances that objects they are interested in have become invalid! However, until we have EC's properly hooked into the psychic-friends network, I don't see how that's going to happen. > If you can get an optimistic lock on ec2.saveChanges out of this technique, > I'll be a fan of it (because then we can just wire this into Wonder on all > EC's and have this problem fixed or at least an opt-in feature), but I'm > still not convinced yet. But that's just it, I don't want to have ec2.saveChanges() fail. By the time that ec2 is back to running, it's EO's have been updated and it's good to save! The delegate gives the application developer the control to handle this case in way specific to their application implementation. Something that I could not divine a general solution too! And yes, by the by, I'm pretty sure that you're correct that when the delegate is called, it's within the thread of the EC which posted the notification and thus throwing any exception would never make it to the handler of another EC. Nor should it! ;-) Now, having said all that, I would be open to the idea of making this easier to understand for new developers however that must not come at the cost of sacrificing the notification that objects have changed from what you thought they were. M. _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
