[cfe-commits] r49699 - in /cfe/trunk: Driver/ASTConsumers.cpp include/clang/AST/DeclObjC.h include/clang/Parse/Action.h include/clang/Parse/Parser.h lib/AST/DeclObjC.cpp lib/Parse/ParseObjc.cpp lib/Sema/Sema.h lib/Sema/SemaDeclObjC.cpp

[Chris Lattner]

On Apr 16, 2008, at 11:48 AM, Fariborz Jahanian wrote:

>
> On Apr 15, 2008, at 8:24 PM, Chris Lattner wrote:
>>
>> On Apr 15, 2008, at 5:17 PM, Steve Naroff wrote:
>>> On Apr 15, 2008, at 4:47 PM, Chris Lattner wrote:
>>>>
>>>> Ok, I guess what I'm getting at is that it would be nice for  
>>>> interfaces to have a single list of "stuff in them", which would  
>>>> include ivars and properties.  Maybe there should be a class  
>>>> below FieldDecl that PropertyDecl and FieldDecl both inherit from?
>>>>
>>>> I admit I'm out of my league here, Steve what do you think?
>>>>
>>>
>>> I don't think it makes sense for ObjCPropertyDecl to inherit from  
>>> FieldDecl (BitWidth doesn't make sense).
>>>
>>> To some degree, I think the AST's reflect ObjC's adhoc syntax.  
>>> Instance variables are modeled directly after structure fields  
>>> (which is reflected in the hierarchy). On the other hand, methods  
>>> are modeled loosely after Smalltalk...no relation to C-style decls  
>>> (so they inherit from Decl). Properties are somewhere in the  
>>> middle...they use C-style naming to access setter/getter methods  
>>> (largely syntactic sugar). The only common super type is Decl,  
>>> which I don't see a problem with (for the moment, at least).
>>
>> Ok, fair enough!  Thanks.  Next (potentially silly) question:  
>> ObjCInterfaceDecl currently has a list of ivars and a  list of  
>> properties, should it be changed to have a list of Decl*'s that can  
>> be either ivars or properties?  I don't have an opinion either way,  
>> I just want to know what you guys think.  ObjCInterfaceDecl has a  
>> lot of stuff in it :)
>
> I would say no. They are distinct and unrelated entities and IMO,  
> belong on separate lists.

Ok!  Thanks for humoring me :)

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20080416/31ab039b/attachment.html>