new DIP5: Properties 2

[Jarrett Billingsley]

On Mon, Jul 27, 2009 at 4:34 PM, Chad
J<chadjoan at __spam.is.bad__gmail.com> wrote:
> Rainer Deyke wrote:
>> Kagamin wrote:
>>> If dip5 is as bad as opGet_foo is I'll delete it right now.
>>
>> What's wrong with opGet_foo?  I like it better than any of the proposed
>> new syntaxes for properties:
>>   - It keeps the language simple by not adding more syntactic clutter.
>>   - In the (very common) case of calculated read-only properties,
>> opGet_foo means less typing.
>>   - With opGet_foo, the semantics of overriding properties in subclasses
>> are obvious.  You can override just the getter, just the setter, or even
>> just one setter of many.  You might also be able to do this with a
>> dedicated syntax, but it's a lot less obvious.
>>
>>
>
> This seems to me like it adds more syntactic clutter than adding a
> keyword would:
>
> PropertyDecl:
>        PropertyGetter
>        PropertySetter
>
> PropertyGetter:
>        Type 'opGet_' Identifier '(' ')'
>
> PropertySetter:
>        Type 'opSet_' Identifier '(' Type ')'
>
>
> Unfortunately, this grammar is wrong.  It needs to be more complicated.
>  That's because there is no whitespace between 'opGet_' and Identifier
> or between 'opSet_' and Identifier.  This is very unusual since just
> about any other pair of tokens in the language is separated by either
> optional or mandatory whitespace (AFAIK).
>
> I understand that opGet_XX and opSet_XX are supposed to be parsed as
> function declarations or somesuch, but I somehow get the feeling that it
> won't fly.  It seems to me like that just makes the semantic analysis do
> some of the parsing work.  That's because the semantic analyzer now has
> to pull apart the op(G|S)et_ from the Identifier and declare a property
> with that identifier as its name.  That step has to be done at some
> point and it seems like parsing would be the more appropriate phase for it.

Nono, I don't think that's really what's being suggested.  It'd work
more like operator overloading.  "opAdd" and the like aren't parsed
any different from any other functions, and they're not represented
differently inside the compiler; they're just functions with "magical"
names.  Similarly, opGet_foo would be a normal function in any way,
and its name would only be significant in the case of "obj.foo", which
*could* be rewritten as "obj.opGet_foo()" (or "obj.opSet_foo").

Also, if you think D can be parsed without any information from the
semantic pass?  I've got news for you..