[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

[Steve Naroff]

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 :)
>

It doesn't make sense to have a single list that can be either ivars  
or properties (since they are in different places syntactically).

It could make sense to have a single list that can be either method or  
properties. The benefit would be 2 less ivars and the ability to  
pretty print them in the order they appeared (at the moment, we loose  
this ordering).

While ObjCInterfaceDecl does have a lot of stuff, it is mostly "Num  
noise" and SourceLocations:-). For example, we have 5 "Num*" ivars  
(this is because we use raw C arrays to store the lists) and 4  
SourceLocations. If we used std::vector, this would be more  
encapsulated. As you know, we have very limited use of std::vector in  
the AST's. As far as the SourceLocations are concerned, I think it  
would be nice to eventually have an IdentifierRef class that knows  
it's SourceLocation (I haven't seen enough value to move in this  
direction).

I'm not seeing any great simplifications here. I'm sure the  
CXXClassDecl will be more complex:-)

snaroff

> -Chris

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