Re: On self = [super init...] ...
Re: On self = [super init...] ...
- Subject: Re: On self = [super init...] ...
- From: John Engelhart <email@hidden>
- Date: Thu, 18 Nov 2010 17:34:39 -0500
On Thu, Nov 18, 2010 at 4:16 PM, Bill Bumgarner <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden