DIP4: Properties

Daniel Keep daniel.keep.lists at gmail.com
Sun Jul 26 09:29:15 PDT 2009



Leandro Lucarella wrote:
> Daniel Keep, el 27 de julio a las 01:09 me escribiste:
>>
>> Leandro Lucarella wrote:
>>> Nick Sabalausky, el 24 de julio a las 00:39 me escribiste:
>>>>  An alternate usage/definition syntax for properties.
>>>>
>>>> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4
>>>>
>>>> Note that there are a few parts marked NEED HELP, that could use assistance 
>>>> from someone with more expertise in this than me.
>>> After reading all the threads again, I think the best proposal is the
>>> opGet_foo() / opSet_foo() for diferentiating functions and properties.
>>> I think is the more D-ish solution.
>>>
>>> I don't like the "_name" though, because it adds semantic infomation to
>>> the identifier, maybe a more template-like syntax can be used:
>> That would involve changing template syntax to allow for identifiers to
>> be passed as an argument.
>>
>> Besides, templates can't be used as virtual methods, so they can't be
>> overridden and can't appear in interfaces.
> 
> Syntax don't have to be changed, unless templates are not allowed
> (syntactically) in interfaces (I'm too lazy to check right now :).
> 
> And template syntax don't have to change either. This is already valid
> AFAIK syntax AFAIK. What it has to be changed, is the semantics, because
> int opGet(foo)(); should be interpreted as a read property instead of
> a templated function.

Ok, I should have said "semantics" instead of syntax.

The thing is you're proposing that template syntax doesn't *actually*
mean a template if the identifier is "opGet".  opGet effectively becomes
a keyword; so you may as well just bite the bullet and add "property" as
a keyword.

>>> ...
>>>
>>> I used an example without trivial properties because... well, you just use
>>> member variables for that. That's why I don't see real value in adding
>>> default properties getter/setters.
>> interface I
>> {
>>     int opGet_value();
>> }
>>
>> You cannot use fields in an interface.
> 
> Yes, and...?

You have an interface.  One of the things it needs to do is provide
access to a field.  You can't just declare a field; you have to have an
accessor.  In most situations, the implementation will simply want to
expose some internal field.



More information about the Digitalmars-d mailing list