Pending issues wrt integrating objc-improvements-branch with mainline

[Ziemowit Laski]

On 3 Aug, 2004, at 11.30, Mark Mitchell wrote:

> Ziemowit Laski wrote:
>
>> (1) How should I discharge my obligation regarding ObjC++  
>> documentation?  Given that there is next to no _ObjC_ documentation
>>     in GCC at present :-), I am tempted to simply point GCC users at
>>
>>          
>> http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/ 
>> index.html
>>
>>     which discusses both ObjC and ObjC++.  Would this be OK, and if 
>> so,  where should I insert it?
>
> I think that's an OK reference.  As for where to insert it, I would 
> think that the place in the manual where you describe the switch that 
> activates Objective-C++ would be good.

OK; I guess the manual would apply to both '-x objective-c' and '-x 
objective-c++'.

> There are a lot of things not documented in the brief section in 
> Objective-C++ in the manual.  For example, can you do overload 
> resolution on functions which take an Objective-C class and how does 
> that work?  Can you instantiate a template with an Objective-C class?  
> Etc.

The answers are "no" and "yes", respectively, but generally you do 
raise an excellent point. :-)  To the extent that the documentation on 
the Apple developer website is incomplete (as it clearly is), I would 
be inclined to get in touch with our developer documentation folks and 
get it updated, so that all the documentation is in one place.

In the future, we could try and start migrating the information from 
the Apple site into gcc/doc/.  I honestly don't know (and shall happily 
defer to others) whether this is a good idea or not, since 
documentation drift/rot may result.  But I guess we can deal with this 
later on.
>
> I think the situation you are in is that without any specification of 
> that behavior, you are getting what you get.  That includes the fact 
> that changes to the C++ front end in these areas may affect 
> Objective-C++.  If that happens, I don't think people will look 
> favorably at trying to add back the old behavior to preserve 
> Objective-C++ semantics.  So, your expectation should be that 
> Objective-C++ code might break over time, if the C++ side of things 
> moves around.

Indeed; unspecified behavior is subject to change. :-)  At the same 
time, over time we may flesh out some of the undefined areas.  Of 
course, such fleshing out will involve updating the documentation, as 
well as adding new test cases.
>
>> (2) How would you like me to stage the actual integration once it is  
>> ready to happen?  To minimize the burden placed on other maintainers,
>>     I propose to break this down as follows:
>>       (a1)  Merge in (minor) changes to the C front-end;
>>       (a2)  Merge in changes specific to the objc/ and 
>> testsuite/objc*  directories;
>>       (b)   Merge in the c-objc-common and cp/cp-objcp-common  
>> lang-hooks rewrite (this basically just moves stuff around);
>>       (c1)  Merge in changes to the C++ front-end; aside from a big 
>> new  chunk going into cp/parser.c, these are also minor;
>>       (c2)  Merge in the objcp/ and testsuite/obj-c++.dg/ directories.
>>
>>     This assumes that (a1) and (a2) occur quasi-simultaneously,  
>> followed by (b) and then by (c1)-(c2) (also quasi-simultaneously).
>>     I can carry out (a2) and (c2) under my ObjC/ObjC++ mullah powers, 
>>  but will need global maintainer approval for the other three.
>
> This seems like a good plan.  I can review (c1); you'll need someone 
> else (Joseph Myers?) for (a1) and (b).
>
> Good luck,

Thanks,

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477