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
> firs
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
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
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
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