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.

On Mon, Nov 30, 2009 at 7:12 PM, Walter Bright <newshound1@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

Bill Baxter wrote:
> On Mon, Nov 30, 2009 at 7:12 PM, Walter Bright
> <newshound1@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.

Andrei

Andrei Alexandrescu wrote:
> Bill Baxter wrote:
>> On Mon, Nov 30, 2009 at 7:12 PM, Walter Bright
>> <newshound1@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.

Andrei Alexandrescu wrote:
> Bill Baxter wrote:
>> On Mon, Nov 30, 2009 at 7:12 PM, Walter Bright
>> <newshound1@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.

But isn't it the same problem with overloaded functions?
Or is this specific issue already solved in D2? (A short look in the language specification revealed nothing; is the unary & operator even documented?)

> Andrei

Walter Bright wrote:
> Simen kjaeraas wrote:
>> I'm already in love with this feature.
> 
> So am I. It seems to be incredibly powerful.
> 
> Looks to me you can do things like:
> 
> 1. hook up to COM's IDispatch
> 
> 2. create 'classes' at runtime
> 
> 3. add methods to existing classes (monkey patching) that allow such extensions
> 
> 4. provide an easy way for users to add plugins to an app
> 
> 5. the already mentioned "swizzler" functions that are generated at runtime based on the name of the function

Can you show examples of points 2, 3 and 4?

I can't see antyhing "dynamic" in this feature. I can't invoke an object's method based on it's name:

class Foo {

  void opDispatch(string name)() { ... }

}

Foo foo = new Foo();

string something = get_user_input();
foo.opDispatch!(something)(); // no, can't do it
foo.something(); // not the same...

So where's the magic? I think opDispatch is just another metaprogramming feature, nothing else.

On Mon, 30 Nov 2009 22:33:40 -0800, Walter Bright <newshound1@digitalmars.com> wrote:

>
>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.

Bill rightfully mentioned that it would be impossible to dynamically dispatch to both properties and methods even if those properties and methods don't have conflicting names. And that may really be an unfortunate limitation. For example, it would be problematic to implement a generic wrapper for IDispatch:

class ComDispatcher
{
   this(IUnknown iUnk)
   {
      // query IDispatch and possibly create a member-names-to-id map,
etc.
   }

   Variant opDispatch(string method, T...)(T args)
   {
      // call method (using DISPATCH_METHOD)
   }

   @property
   void opDispatch(string property, T)(T arg)
   {
      // set property (using DISPATCH_PROPERTYPUT)
   }

   @property
   Variant opDispatch(string property)()
   {
      // get property (using DISPATCH_PROPERTYGET)
   }
}

auto c = new ComDispatcher(iUnk);
c.foo(1); // call method
c.bar = 1; // set property
int a = c.baz; // get property
int b = c.qux(); // call method

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

> Andrei Alexandrescu wrote:
>> Bill Baxter wrote:
>>> On Mon, Nov 30, 2009 at 7:12 PM, Walter Bright
>>> <newshound1@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-@property version called

Max Samukha wrote:
> On Mon, 30 Nov 2009 22:33:40 -0800, Walter Bright
> <newshound1@digitalmars.com> wrote:
> 
>> 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.
> 
> Bill rightfully mentioned that it would be impossible to dynamically
> dispatch to both properties and methods even if those properties and
> methods don't have conflicting names. And that may really be an
> unfortunate limitation. For example, it would be problematic to
> implement a generic wrapper for IDispatch:

Is there any reason not to just make the IDispatch properties have a function interface?

Ary Borenszweig wrote:
> Can you show examples of points 2, 3 and 4?

Have opDispatch look up the string in an associative array that returns an associated delegate, then call the delegate.

The dynamic part will be loading up the associative array at run time.