On 21 May 2010, at 10:12, Richard Guenther wrote:
On Thu, May 20, 2010 at 10:20 PM, Steven Bosscher <stevenb....@gmail.com
> wrote:
On Thu, May 20, 2010 at 9:54 PM, IainS <develo...@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
