在 Fri, 17 Apr 2009 23:27:38 +0800，Steven Schveighoffer
<[email protected]> 写道:
On Fri, 17 Apr 2009 11:11:55 -0400, davidl <[email protected]> wrote:
在 Fri, 17 Apr 2009 22:24:04 +0800，Steven Schveighoffer
<[email protected]> 写道:
On Fri, 17 Apr 2009 09:44:09 -0400, Leandro Lucarella
<[email protected]> 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.
But if you want a dynamic property, you won't want to do it in that way.
You actually make the opDot to do:
void opDot(char[] methodname, ...)
{
if (methodname = "prop")
{
// deal with the vararg to get the int x
// assign it to _prop, then you're done.
// or you can call the prop func here by reconstructing the vararg.
}
}
Notice that if statement can be done by a delegate. Thus when you add a
property you simply add your delegate func to the class. And opDot call
those delegates one by one.
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.
Yes, these problems can happen across plugins/host, database design/db
apps. Host can't validate its plugins. Host doesn't know what plugins can
provide. DB apps which I know don't have much fancy technics to be future
proof (what if my db design changes? those SQL won't immediately fail at
compile time, only when you run it.)
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?
The benefit is you don't need to write the call function, you don't need
to write the string quote. Take a look at my other posts about the
usecases of this proposal(ddl, ddbi).
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
Actually different, Walter needs to modify the overload mechanism in the
current compiler for different function finger prints. What I need to do
is sending the return type to the opDot method. Because the overloading is
done by the opDot func at runtime, so I don't have Walter's difficulty in
dealing with overloading :D
--
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
