[cfe-dev] [clang] declspec(property...) advice

[Douglas Gregor]

Sent from my iPhone

On Dec 8, 2010, at 11:53 AM, Eric Niebler <eric at boostpro.com> wrote:

> On 12/8/2010 1:16 PM, Douglas Gregor wrote:
>> 
>> On Dec 8, 2010, at 9:56 AM, Eric Niebler wrote:
> 
>>> 2) If the attribute is the right approach, is storing the getters 
>>> and setters as strings sensible? FWIW, Microsoft doesn't catch 
>>> typos in the getter/setter declaration until the property is 
>>> actually referenced, which seems to suggest that its doing a
>>> fairly primitive rewrite at the point of use. So strings would
>>> work, IIUC. It does not eagerly perform name lookup of the getters
>>> and setters within the class definition.
>> 
>> It makes sense to delay the lookup of the get/put names until after 
>> the class is defined (like we do with default arguments and inline 
>> member function bodies), but I find it really gross that name lookup 
>> doesn't occur until the property is actually referenced.
> 
> I agree, it's a bit gross. I can't think of a case where performing
> name-lookup at the end of the class definition would produce different
> results,

It could matter when the code is ill-formed because the get or put operation doesn't exist (or can't be called). MS probably doesn't diagnose this until the property is used.

> but I'm a bit wary of trying to be smarter than the MS compiler
> when the ultimate goal is feature parity with MS.

We always have to weigh compatibility against solid design. Should every client of the AST have to cope with the possibility that the get or put operation hasn't been resolved? There's a real cost there.

>>> 3) Where should the rewrite happen? Is it OK to leave in
>>> references to the pseudo-field in the AST, or should the AST
>>> reflect what will actually be executed -- invocations of the
>>> getters and setters? My instinct tells me that the AST should have
>>> the pseudo-field, not the getters and setters. Anything else might 
>>> confuse things like IDEs.
>> 
>> The AST should have the pseudo-field (possibly with a special 
>> "MSPropertyRefExpr" expression type to reference them), and we
>> should introduce implicit AST nodes (e.g., an ImplicitCastExpr
>> wrapping a call) to handle the get and put calls. 
> 
> I'm afraid I didn't follow that.

Somehow, you need to represent an expression

  foo.property

That probably means creating a new expression node type. This expression node type may be used in an assignment (calling the put operation) or via an lvalue-to-rvalue conversion (calling the get operation), which will be represented via implicitly-generated AST nodes. 

>> You're in luck,
>> though: Objective-C has properties, and John McCall is currently
>> refactoring lvalue-to-rvalue conversions to make properties (and
>> other constructs) more explicit and cleaner. You should be able to
>> use the Objective-C property implementation as a guide and follow
>> what John is currently doing to implement this feature.
> 
> OK, then I might just put off further work on this feature until the
> refactorization is done and I have John's work to crib from.

No need to wait. You can get fairly far without tripping over John's work. 

  - Doug