If I had my way

Timon Gehr timon.gehr at gmx.ch
Wed Dec 14 00:28:12 PST 2011


On 12/14/2011 06:25 AM, Jonathan M Davis wrote:
> On Wednesday, December 14, 2011 03:45:35 F i L wrote:
>> Jonathan M Davis wrote:
>>> The simplest solution would be to simply have the function
>>> callable as a non-
>>> property function when there's such an ambiguity, but that does
>>> go against the whole "require a property function to be used as
>>> a property" thing. Your suggested syntax is pretty good, but
>>> it's not exactly a desirable solution either. I don't know.
>>> Given the simplicity of it and the fact that there's no way
>>> that you're going to change the property function to a member
>>> variable (since it's not like you can add it to arrays),
>>> allowing for it to be called as normal function seems like the
>>> better solution, albeit not exactly ideal. Free functions
>>> definitely complicate the whole property thing.
>>>
>>> - Jonathan M Davis
>>
>> Honestly I'm kind of a fan of having any method with zero or one
>> parameters being usable as properties or methods at the
>> programmer's discretion. Then conflicting pseudo methods could
>> just be resolved through normal method semantics as you
>> described. But I understand this is being removed so there must
>> be a reason for it.
>
> It was in part due to ambiguity with regards to delegates. Also, a fairly
> typical argument for properties is the ability to swap public member variables
> and property functions. That's not possible if you can't classify a function
> such that it _must_ be called as a property.
>
> - Jonathan M Davis

The transition most of the time goes field -> property. Then it is not 
necessary at all. I think proper properties > implicit properties = no 
properties > implicit properties with enforcement.


More information about the Digitalmars-d mailing list