Re: On self = [super init...] ...
On Nov 18, 2010, at 2:34 PM, John Engelhart wrote: > 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? The documentation says: In general, if there is a problem during an initialization method, you should call [self release]and return nil. Thus, no, there is no problem if multiple classes in the hierarchy participate. The only stumbling point is that this: self = [super init]; May cause 'self' to be released; if you have code that is still referring to self via some other means, it better had darned well retained it before making that call. b.bum ___ 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
Re: On self = [super init...] ...
On Nov 18, 2010, at 4:34 PM, John Engelhart wrote: > 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. That just sounds like making bad assumptions to me. If you have special needs that subclasses have to be aware of beyond the usual things, then you should be documenting these requirements, just like Apple does with many classes which tell you the designated initializer that you should use, what primitives need to be overridden, or in some cases, that a class is not meant to be subclassed. Charles___ 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
Re: On self = [super init...] ...
On Thu, Nov 18, 2010 at 4:16 PM, Bill Bumgarner 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
Re: On self = [super init...] ...
On 18 Nov 2010, at 21:16, Bill Bumgarner 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? > > 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. > > 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? Indeed, the behaviour of immutable strings and containers seem to back up this assertion #import int main (int argc, char ** argv) { NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; NSString *s1 = @""; NSString *s2 = [NSString stringWithString:s1]; NSString *s3 = [NSString alloc]; NSString *s4 = [s3 initWithString:s2]; NSLog(@"%p, %p, %p, %p", s1, s2, s3, s4); [pool drain]; } prints 2010-11-18 21:39:35.767 Test[18767:a0f] 0x11050, 0x11050, 0x10010d470, 0x11050 So our allocated string is certainly substituted during initialisation. Bob___ 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
Re: On self = [super init...] ...
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? 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. 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? b.bum ___ 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