[Top][All Lists]

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

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

From: Kaelin Colclasure
Subject: Re: PATCH: Merge objc-improvements-branch to mainline
Date: Wed, 24 Sep 2003 17:03:00 -0700

On Wednesday, September 24, 2003, at 02:59  PM, Banlu Kemiyatorn wrote:

David Ayers wrote:

Stan Shebs wrote:

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

I don't find this a convincing argument to introduce more non portabilities. Yes the existing ones should be dealt with, but even more important is not to introduce any new ones. Let's deal with them before they hit the trunk. And the only way I can see us doing that, is if we break this patch down.


As a user, I agree with David and I think this improvements will only pollute the nicest part of the language itself. I'd like to ask any one who's reading this to share your opinions
that you really agree with this patch so you are quiet or not.
Best regards.

Also as a user, I have the opposite opinion: I think these additions are substantial improvements to the ObjC language and I would be very disappointed to see them blocked.

I like ObjC, but I fall strongly into the camp that maintains library-level exception handling is inadequate given the evolutionary trend towards larger and larger register compliments in modern processors. Yes, it's true that as it stands this patch does nothing to improve the efficiency of establishing handler blocks -- but by establishing this as the provence of the compiler, the way is paved for future improvements to the implementation that are simply not possible with a library.

The addition of @synchronized, likewise, has great potential for improving the correctness of code written in ObjC. To dismiss it (and @finally) as syntactic sugar implies a less-than-complete understanding of the subtleties involved in writing correct code in the absence of these constructs.

And finally, I am encouraged to see ObjC continuing to evolve as a language, and I am pleased to see Apple making a sincere effort to "do the right thing" by actively participating here to coordinate their contributions to that evolution with the wider ObjC community. Yes, it would be *even better* if Apple could commit their resources to also making every new feature functional with the GNU runtime as well as their own... But I think it's counterproductive to mandate that this be done before Apple's code can be merged.

-- Kaelin

reply via email to

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