Proposal: remove the Obj-C++ front end

[IainS]

On 21 May 2010, at 10:12, Richard Guenther wrote:

> On Thu, May 20, 2010 at 10:20 PM, Steven Bosscher <stevenb.gcc@gmail.com 
> > wrote:
>> On Thu, May 20, 2010 at 9:54 PM, IainS <developer@sandoe-acoustics.co.uk 
>> > wrote:
>>> No Asbestos required - but .. I do have some observations..
>>>
>>>  I write pretty much all my serious (day-job) code in ObjC and..
>>> ...  I have stated that it's an intention to make *that*, at least  
>>> work at
>>> V2 on FSF.
>>>
>>> Having said that:
>>>
>>> a)  I have not anything like as much attachment to ObjC++ ...
>>> b) We are all limited in the amount of time we can allocate to  
>>> FSF ..
>>
>> Right. I am not suggesting ObjC should go away at all. It clearly has
>> users and it's pretty much isolated. It mixes with the C front end,  
>> of
>> course, but that is not a problem. With ObjC++, you have a front end
>> trying to unify the C, ObjC, and C++ front ends with itself. That's
>> not even comparable.
>>
>> Besides, the ObjC language makes sense, whereas Obj-C++ combines the
>> worst of ObjC with the worst of C++ (or so I'm told by people who
>> should know what they're talking about ;-)
>
> I thought Obj-C++ was most about ObjC - C++ interoperability
> because all the OS-X UI runtime is written in ObjC which makes
> it hard to write a pure C++ GUI application.

It's quite possible to do the Qt thing, and it's done successfully on  
OSX/Darwin - as is java gui.

However, that isn't the point.

Favorite flavors aside - assuming that one wishes to use ObjC as a  
development platform on Darwin, it is necessary at times to access  
important system components written in c++.   We should ensure that we  
don't lose this ability in whatever step is taken next.

It is also the case that a gnu-objc user on linux would wish to  
incorporate c++ - even the inverse of the darwin scenario.

In my ideal world, I would be able to write my gui in ObjC, leverage  
legacy C stuff, connect in my CFD code in Fortran and utilize open  
source c++ GIS code - in the same application.

(Of course, that's speaking as a User, rather than volunteering to  
implement it).

===

I'd argue for:
Please allow us the opportunity to make significant progress towards  
resolving the issues by end 4.6 ..

If that is not "significant enough" then we could fork the c++  
components of ObjC++ and detach it from the live c++ ..
... it would be stagnant but not dead (not much different from the  
state since 4.3).

I personally have a higher priority on ObjC - but would seriously  
expect that effort spent there will benefit ObjC++ ...

The code is currently 99% or so shared.

for example, ... we could macro-ize the differences in build_xxx  
rather then expecting c++ people to wrap things (I wasn't expecting it  
actually, ;-))

of course it isn't my call.. and I can't seriously volunteer to solve  
all the problems, but IMO there ought to be reasonable engineering  
solutions..
(as alternatives to rm -rf)
Iain