dynamic classes and duck typing

[Denis Koroskin]

On Tue, 01 Dec 2009 09:33:40 +0300, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Andrei Alexandrescu wrote:
>> Bill Baxter wrote:
>>> On Mon, Nov 30, 2009 at 7:12 PM, Walter Bright
>>> <newshound1 at digitalmars.com> wrote:
>>>> Bill Baxter wrote:
>>>>> So we can overload on @property-ness?
>>>> No.
>>>>
>>>>> I.e. this works
>>>>>
>>>>> struct S
>>>>> {
>>>>> @property
>>>>> float x() { return 1.0f; }
>>>>> float x() { return 2.0f; }
>>>>> }
>>>>>
>>>>> void main()
>>>>> {
>>>>>    S  s;
>>>>>    writefln("%s", s.x); // writes 1.0
>>>>>    writefln("%s", s.x()); // writes 2.0
>>>>> }
>>>> That just looks wrong.
>>>>
>>>
>>> Ok, so you can't have both dynamic properties and dynamic methods with
>>> this.  One or the other, your pick.
>>> Seems like an unfortunate limitation.
>>>
>>> --bb
>>  It's a limitation similar to not having a field and a method share the  
>> same name. It avoids a number of awkward questions such as figuring the  
>> meaning of &s.x.
>
> I agree. While the compiler currently doesn't check for mixing up  
> properties and methods, I intend to make it do so. I can't see any  
> justification for allowing it.

Monkey-patching relies on it:

int bar() { return 42; }

Dynamic dynamic = new Dynamic();

dynamic.newMethod = &bar; // setter, @property version called
auto dg = dynamic.newMethod; // getter, @property version called

auto result = dynamic.newMethod(); // non- at property version called