On Thu, Nov 18, 2010 at 4:16 PM, Bill Bumgarner <b...@mac.com> wrote:
> > On Nov 18, 2010, at 1:10 PM, John Engelhart wrote: > > The basic premise behind self = [super init...] is that the "lower levels > of initialization are free to return a different object than the one passed > in". > > However, there is an unstated assumption in this reasoning: whatever object > is returned by [super init...] is the one that will be used. > > > I don't understand the above claim; Why must the object returned by [super > init*] be the one that is used? > That's a fair question. I can see two general cases: 1) It doesn't matter at all if the object you return is used. 2) It really matters whether or not the object you return is used. For the first case, it seems fair to ask the question "If you choose to return a different object than the 'original' one, and it doesn't matter that that choice be honored, then why are you returning a different object in the first place?" This leads directly to the second case: It really matters whether or not the object you return is the one that is used. Now, can both policies be supported using the same init... interface? Probably not. In fact, just about anyone or anything that's going to do object substitution is doing it for a reason, and that reason really matters. If it doesn't, then I should be able to take NSMangedObjects, ignore and discard the returned object, instantiate another object (which may not be of the NSMangedObject class), and just magically have everything "work". If it truly doesn't matter whether or not the choice of which object is returned be honored, you're going to have an awful lot of people complaining about why the object they substituted isn't the one that's being used. Let's face it: From a pragmatic perspective, there's only one policy that makes any sense: if a object substitution is permitted, then the substituted object is the one that has to be used. But your objection is still from the perspective of the "tail end". It still doesn't address the case when I'm performing object substitution "above you" and I really, really need you to honor my choice. In this case, if you decide to substitute a different object after I've already done so, and I made my choice for reasons that are not available to you, we've got problems. Not only that, it is impossible for you to even tell that I'm in the middle of performing object substitution "above you" and not just performing the required self = [super init...]. At some point, someone is going to require either the choice be honored at the "head" or at the "tail", and possibly both. > I'm certainly not aware of any limitation on an init method that would > prevent it from… say… calling [super init], releasing whatever is returned > if deemed unfit and then allocating an initializing some other instance. > I am. Lets say I made an object substitution for "some reason", and I really need my substituted object to be the one that's used because it has red racing stripes or something. Then if your lower in the class hierarchy init... method is just going to -dealloc my object and do something else (you know, basically exactly what I'm trying to do with my own object substitution, hint hint), then what's the point in even trying to do object substitution in the first place? Someones object substitution choice needs to "stick". And I'm willing to bet that anyone or anything that is doing any form of object substitution does not correctly handle the case when their choice isn't the one that "wins". > The documentation ( > http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/ObjectiveC/Articles/ocAllocInit.html) > doesn't seem to make any such claim either. > > I haven't read beyond the above yet. Maybe the unstated assumption is > explained? > Ok, let's assume three uncoordinated (that is to say, nothing more that the self = [super init...] requirement) classes within some class init... hierarchy are all attempting to do object substitution, and each of the classes is doing object substitution "for a reason" (i.e., the case where it really matters). Do you see a problem? It works great if you're the only class in the init... hierarchy that's doing it. As soon as two or more classes within a init... hierarchy start doing object substitution, there's a problem. _______________________________________________ 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
