dynamic classes and duck typing

Leandro Lucarella llucax at gmail.com
Tue Dec 1 05:47:53 PST 2009


Walter Bright, el 30 de noviembre a las 22:33 me escribiste:
> 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.

What about:

@property int opDispatch(string n)() if (n.startsWith("prop_"))
{
	// ...
}

int opDispatch(string n)() if (n.startsWith("meth_"))
{
	// ...
}

int i = o.prop_x;
int j = o.meth_x();

Should this work? Is not that pretty, but it's a compromise.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Y tuve amores, que fue uno sólo
El que me dejó de a pie y me enseñó todo...



More information about the Digitalmars-d mailing list