[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

[Fariborz Jahanian]

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.

- Fariborz

>
> -Chris

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