Re: Cocoa and dead-code stripping
Re: Cocoa and dead-code stripping
- Subject: Re: Cocoa and dead-code stripping
- From: Chris Hanson <email@hidden>
- Date: Tue, 3 Jul 2007 15:03:28 -0700
On Jul 3, 2007, at 11:26 AM, Andrew Demkin wrote:
My only point here was to clarify that dynamic messaging isn't a
deal-breaker for automatic stripping. It can be made to work.
Whether it is useful is some cases or others is a separate matter.
It can't be made to work reliably in common use though, which is the
key difference from dead-code stripping in C/C++; in C/C++, you can
assume that anything that isn't explicitly exported from your linked
result and isn't called within it can be stripped. In Objective-C you
must assume everything is exported.
For a concrete example, most of the Cocoa applications I've worked on
over the past decade have implemented menu item validation by
composing individual validation selectors based on the menu item's
action selector. So for a menu item whose action is -doSomething:,
the generic validation code would compose a selector like -
canDoSomething:. It would then see which object in the responder
chain will handle -doSomething:, check if that object implements -
canDoSomething: as well, and if it does use that to determine whether
to enable the menu item.
The implementation of -canDoSomething: would most likely look like
dead code to most automated dead-code stripping mechanisms, even
though there's a significant chance it would be invoked at run time.
(Of course it would be invoked by unit tests during build too, but
dead-code stripping wouldn't know about that.)
Stripping in Smalltalk isn't really all that similar to dead-code
stripping in C/C++ either; typically it's a much more interactive
process to figure out which parts of a system image are and aren't
used by the standalone application you want to generate. It's also
made easier by the fact that despite being a more dynamic language
than Objective-C, in practice selectors are much less likely to be
composed on the fly.
Nonetheless, modern Smalltalk implementations have been moving away
from stripping out unneeded classes to deliver standalone
applications. Instead, they're adopting packaging mechanisms that
allow a developer to specify what parts of the system they want to
include in the end product. The environment uses this information
along with namespaces to guide development such that the selected
packages will be correctly composed together into an end product
whenever the developer generates one. As a result, the developer
experience in modern Smalltalk environments has become very similar to
developing with Objective-C frameworks on Mac OS X.
-- Chris
_______________________________________________
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