Hello Steve,
steve naroff wrote:
When ObjC++ was written, there was thought/hope that the ANSI-C and
ANSI-C++ standardization efforts would "converge" (and it would
become the "modern" dialect). Since they never did, we are left with
two dialects of ObjC (unfortunately...we would prefer to have one:-)
Hmm, is this a subtle suggestion that 'you' ('we' as in Apple?) would
prefer to only have ObjC++? Call me paranoid but that thought alone
is quite frightening. :-) (But also currently irrelevant.)
Here are some answers to your questions...
Will the objc++ frontend work with the GNU runtime?
Yes. Objective-C++ didn't require any changes to the Apple
runtime...the same should be true for the GNU runtime.
This is wonderful news!
Are there any other platform dependencies that you are already aware
of (i.e. other that the potential dependency on the Apple Runtime)?
No.
Even better!
IIRC, it was mentioned, that this is a new frontend which will make
use of some of the source files (e.g. objc-act.c) in the current
objc frontend. I expect that there are some tweaks needed, so we
should continue testing the objc frontend of the branch, right?
Absolutely. Layering ObjC atop C++ can potentially introduce
regressions...
OK, so once things stabilize on the branch, I'll see if I can churn it
through GNUstep.
Thanks,
David
PS: I realize that ObjC++ has a history on NeXT/Apple's platforms and
that you'll want 'your' (aka Apple's) version to be binary compatible
on Darwin. So if it turns out that there are quirks that show up on
other platforms we should try to solve them in binary compatible
fashion wrt Darwin if elegantly possible but I hope you agree with me,
that the FSF tree may diverge to gain more portability as there is
nothing to be backward compatible too wrt to ObjC++ on anything but
Darwin. But from your assurances, I'll assume that this currently a
non-issue.