On Fri, 17 Apr 2009 11:11:55 -0400, davidl <dav...@nospam.org> wrote:
在 Fri, 17 Apr 2009 22:24:04 +0800，Steven Schveighoffer
<schvei...@yahoo.com> 写道:
On Fri, 17 Apr 2009 09:44:09 -0400, Leandro Lucarella
<llu...@gmail.com> wrote:
I don't fully understand the example though. In writefln((v.qq = 5).i),
how is that B.i is assigned to 5 if the opDotExp("qq", 5) don't
propagate
the 5 to the new B()?
I think it translates to
opDotExp("qq") = 5
Without knowing the signature of qq, how is the compiler supposed to
infer that it is a property? In fact, I think this might be a
limitation of this syntax, you can't define dynamic properties.
The opDotExp overload func is supposed to deal with that, because it's
in your hand to deal with the dynamic properties. The example here is
illustrating the dynamic properties.
except, you can't define a property like:
void prop(int x)
{
_prop = x ^ ~0;
}
Using a dynamic method.
I for one, can't really see a huge benefit, but then again, I don't
normally work with dynamic-type langauges. It looks to me like a huge
hole that the compiler will ignore bugs that would have been caught if
the methods were strongly typed:
class c
{
void opDotExp(char[] methodname,...)
{
if(methodname == "mymethod")
callMyMethod();
else
throw new Exception("bad method name: " ~ methodname);
}
}
void foo(c myc, bool rarelySetToTrue)
{
if(rarelySetToTrue)
myc.mymethud(); // compiles, will throw runtime exception
}
The problem is you're dealing with the class which is overloaded its
opDot. You know the risk before hand, you are not going to overload for
every classes. Here, you seem to little bit overrate this feature. :)
If you want things checked, then you probabely need to go back to
static. This dynamic stuff is used for dynamic things only, and as long
as you have to do it in the dynamic way that means you have no easy way
or even impossible to check it at compiletime and you accept the
potential risk like the example you posted.
Sure, but what is the reason to need dynamic methods? I'm just trying to
understand the usefulness of it. If a method is dynamic, we lose the
following things:
- compile-time type/signature checking
- IDE assistance in determining which methods are available
- ease of tracing where a method call goes.
- not future proof -- for example, if a method name gets changed or moved,
the code using the method still compiles.
If we lose all these things, there must be *something* we gain by doing
this, right?
Also, what is the benefit of doing something like this versus specifically
calling the dispatcher instead of having the compiler translate it?
Also, how do you overload the return value? Using this proposal, you
can't have different dynamic methods that return different types.
Umm, maybe make the compiler to pass the return type into the opDot
would allow the opDot func to decide which overload func to call.
Walter already has issues overloading on return type, I'm not sure this is
any different.
-Steve
