• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: why Obj-C
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: why Obj-C


  • Subject: Re: why Obj-C
  • From: Chris Purcell <email@hidden>
  • Date: Fri, 5 Apr 2002 14:28:29 +0100

My apologies, I used notation incorrectly in my response. Perhaps if I remedy:

What I meant was, you cannot be sure a _subclass_ will not override the superclass code called by init - and perhaps for very good reasons! Maybe you are overriding setters to implement undo support, for instance. You would want this to be called whenever the superclass accesses these methods, *except* during initialization when they would be invalid for the duration of the superclasses' init method.

Is it right to ban all overriding of setter methods in subclasses just because the superclass init calls them? No, that might be harshly restrictive. But in order to allow it, the superclass init cannot call any setters. In C++, this is a non-issue as the superclass init method would call the superclass implementation of the setters, and this is exactly what you would want, as it guarantees that at the start of a subclass init method, the superclass is set up *exactly* as it would be were it not subclassed, regardless of what methods were overridden.

(Note I use ObjC notation throughout, not C++, for clarity.)

Here's hoping I've made no more typos.

Kritter out

In fact, isn't

self = [super init];

A rather common thing to place in an init method
(often withing an if conditional)? And accepted as a
good thing to do?

-Byron

--- Ondra Cada <email@hidden> wrote:
On Friday, April 5, 2002, at 11:57 , Chris Purcell
wrote:

Yes, and as a result it is recommended you make no
self calls during an
object's init methods, as they may access data in
a superclass that has
not yet been initialized. The exception is
generally calling self's
designated initializer (as that is supposed to be
called), and possibly
accessors if you can guarantee that no superclass
will ever override them
to do something unexpected. But in general, there
is no way of ensuring
you call the code you yourself have written!

Sorry, but that's a very nice bunch of... total
nonsenses. Just the worst
one: since you've used self's (or super's)
designated initializer first,
you are sure that all superclass data are
initialized. Theoretically
_subclass_ data might be uninitalized, but that's a
problem of implementor
of the subclass (to prevent that);

There's much more (like showing that and why the
fact you can't "guarantee
that no superclass will ever override" this or that
is The Very Right
Thing), but I haven't time for that.
---
Ondra Cada
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: why Obj-C (From: Byron Sinor <email@hidden>)

  • Prev by Date: Re: why Obj-C -> IB evolution
  • Next by Date: Re: Carbon IB items missing in Cocoa
  • Previous by thread: Re: why Obj-C
  • Next by thread: Re: why Obj-C
  • Index(es):
    • Date
    • Thread