Re: Objective-C Question
Re: Objective-C Question
- Subject: Re: Objective-C Question
- From: Andreas Mayer <email@hidden>
- Date: Mon, 22 Sep 2003 16:02:10 +0200
Am Montag, 22.09.03 um 13:38 Uhr schrieb Steve Ehrenfried:
Is this true
in Obj C, or does it allow you to instantiate a class
even though it may have methods defined in the
interface that aren't implemented? Would this generate
a compile or runtime error?
You can instantiate an object of any class.
If a class does not implement a method that is declared in its
interface, you get a compiler warning.
If you send a message to an object that does not understand it, you get
an exception. Of course, you are able to check if an object understands
a specific message before sending it. So it is possible to avoid that
exception.
You can even add categories to classes at runtime. So you might
implement that missing method later on without actually changing the
code of the affected class or that part of the code where the object is
instantiated.
In that case Objective C sucks too. I subsequently
found out that Obj C supports access control for
instance variables, just like C++ and Java. Perhaps
not a lot of people use it.
Subclasses are not normally meant to access instance variables of their
superclasses. You should always use accessors. (In fact you should use
accessors even inside your class.) But there is no access control for
methods whatsoever. You are allowed to send *any* message to *any*
object. It would just complicate the language to add restrictions as of
what messages you are allowed to send to which kind of objects.
Of course encapsulation is a good thing. But I can't see a reason why
it has to be enforced. If you don't want others to use you 'private'
methods, just don't declare them in your header file.
bye. Andreas.
_______________________________________________
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.