Re: PATCH: Merge objc-improvements-branch to mainline

[Stan Shebs <shebs at apple dot com>]

Alexander Malmberg wrote:

> Ziemowit Laski wrote:
>
> > -fobjc-exceptions
>
> ... this is not. This is just a bunch of syntactic sugar; making
> language extensions and new keywords out of functionality that is
> currently implemented in libraries.
>
> The extensions (exceptions and synchronization) have nothing directly to
> do with the rest of objective-c (which is about message passing and
> objects). They take a small, clean, and powerful language and make it
> bigger and less clean without adding any power. They bloat the compiler
> and the runtime, and would impede the development of (new and existing)
> alternative solutions to these problems (implemented in libraries).
>
> I see no reason why this part is worth the trouble it causes. In my
> opinion, this part should not be merged. If necessary, I can clean up
> the patch by removing these parts.
This has been one of the most heavily-requested features for ObjC. While
it's true that it's syntactic sugar, so is for(), and yet few suggest
that it should be removed from C. For that matter, many programmers
contend that ObjC and C++ are unnecessary syntactic sugar too... The
rationale for adding exception handling, aside from the incessant user
requests, is that it is hard to get right manually, plus the manual
solution involves fooling around with explicit flow control in the form
of setjmp/longjmp, which you really want to hide whenever possible.

> > The only "known defect" of the patch is that not all of the
> > -fobjc-exceptions stuff
> > is as platform-independent as it could/should be.
>
> Indeed. It seems that it's even hard-coding the size of libc structures
> (jmp_buf), which is a bug problem for portability. (Are we even
> guaranteed that the size is constant for a system and doesn't vary with
> different libc:s?)
I think we will want to solve it, but that can be done at leisure on the
trunk, since it solves a problem that is presently hypothetical.  There
are other ObjC nonportabilities that are much more urgent to fix, such as
the libobjc use of internal GCC headers, which causes build problems
regularly.

Stan