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

[Kaelin Colclasure]

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
> > > regularly.
> > 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.
> >
> > Cheers,
> > David
>
> 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