[cfe-commits] r60634 - in /cfe/trunk: include/clang/AST/DeclObjC.h lib/AST/DeclObjC.cpp lib/Sema/Sema.h lib/Sema/SemaDeclObjC.cpp test/SemaObjC/property-category-3.m

[Fariborz Jahanian]

On Jan 7, 2009, at 6:34 AM, steve naroff wrote:

>
> On Jan 7, 2009, at 1:47 AM, Daniel Dunbar wrote:
>
>> Fariborz (& Steve),
>>
>> I know this is how some other existing code was being handled, but I
>> am a little concerned about this implementation strategy (copying the
>> properties into the class). This feels counter to clang's general
>> strategy of having the AST closely reflect the source. In addition,  
>> it
>> seems like this means more malloc trashing than is really necessary.
>>
>> My question is, how much work would it be to *not* copy the  
>> properties
>> in this fashion? Is it more complicated than just rewriting the type
>> checking and the property lookup mechanisms?
>>
>
>
> I'm not concerned about the speed of property lookup. With or  
> without the copying, I'm sure property lookup can be made efficient  
> (especially since the cost should be proportional to the number of  
> properties used, vs. declared).
>
> I imagine the copying was originally intended to simplify the lookup  
> mechanism (not speed it up). Fariborz, is this correct? What's your  
> perspective?

I agree that AST should reflect the source and not the implementation  
details. However, in the case of properties, it becomes rather
tricky in some cases. Looking at radar 5957689. If we don't use these  
methods when properties are referenced, then there is
no need for them. However, if methods are used (and thus become part  
of the AST), then they are added. It all depends on how we represent
property assignment and references. To remove all semblance of setter/ 
getter methods, we have to invent new AST nodes for property
references. But as you pointed out, these (property in protocol, and  
above radar) are part of a clean up (A fairly big clean up I might add).
This is because we have to move a lot more intelligence to all the  
clients involved. Drawing the line between simplicity of AST and  
complexity
of the clients becomes quite tricky.

- Fariborz

>