[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stan Shebs
Subject: Re: PATCH: Merge objc-improvements-branch to mainline
Date: Wed, 24 Sep 2003 11:24:44 -0700
User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624

Alexander Malmberg wrote:

Ziemowit Laski wrote:


... 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]