Re: Cocoa and dead-code stripping
Re: Cocoa and dead-code stripping
- Subject: Re: Cocoa and dead-code stripping
- From: Andrew Demkin <email@hidden>
- Date: Mon, 2 Jul 2007 14:51:10 -0700
On Jul 2, 2007, at 10:46 AM, Chris Hanson wrote:
The main caveat to this approach is that you will need to carefully
design your framework's API so that you can maintain binary
compatibility from release to release, if users aren't required to
upgrade all of your plug-ins at once. This isn't all that hard
with Objective-C since the only area where it suffers the fragile
base class problem is in instance size (number and size of ivars);
you can add methods all you want without affecting binary
compatibility with your framework's clients, unlike with C++.
That's not entirely true.
In ObjC there's also the risk of message selector collisions. For
example, I could publish "class Foo" today, and clients of mine could
subclass with "class Bar". In the future, I could try to extend my
Foo class with "someSelector", but if class Bar already had its own
implementation of "someSelector", it's likely my framework won't
behave as expected.
IIRC, C# solved this part of the fragile base class problem by
introducing an explicit "override" keyword into the language. Only if
a subclass specifically declares its intent to override the method in
the base class will the overridden behavior occur. That's a nice
feature.
It's true that this problem doesn't occur all that often in practice,
but it is part of the fragile base class problem that's often
overlooked. The use of "category" methods only makes this risk that
much greater.
( As for the C++ criticism, yeah, in practice you're correct that
it's even easier to get into trouble with virtual functions, but,
technically speaking, it's not a required outcome of the way the
language is defined. Rather, it could be viewed as a quality of
implementation issue. There are also other techniques and conventions
that can mitigate this risk. )
Andrew
_______________________________________________
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