retard wrote:
Tue, 01 Dec 2009 12:40:21 -0500, Steven Schveighoffer wrote:
On Tue, 01 Dec 2009 11:58:43 -0500, Denis Koroskin <2kor...@gmail.com>
wrote:
On Tue, 01 Dec 2009 19:41:46 +0300, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Tue, 01 Dec 2009 11:20:06 -0500, Denis Koroskin <2kor...@gmail.com>
wrote:
On Tue, 01 Dec 2009 19:02:27 +0300, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
You are missing the point of opDispatch. It is not runtime defined,
because the compiler statically decides to call opDispatch. The
dynamic part of opDispatch comes if you want to do something based
on runtime values within the opDispatch function. e.g. the compiler
doesn't decide at *runtime* whether to call opDispatch or some
normal function named quack, it's decided at compile time.
opDispatch could be completely compile-time defined since it is a
template. But the 'dynamicness' of it is basically no more dynamic
than a normal function which does something based on runtime values.
Compare that to a dynamic language with which you can add methods to
any object instance to make it different than another object, or
make it conform to some interface.
Well, I believe it's possible to implement the same with opDispatch
(not just to any object, but to those that support it):
void foo() {}
Dynamic d = ..;
if (!d.foo) {
d.foo = &foo;
}
d.foo();
You could do something like this (I don't think your exact syntax
would work), but you could also do something like this without
opDispatch. But the name 'foo' is still statically decided. Note that
opDispatch doesn't implement this ability for you, you still have to
implement the dynamic calls behind it. The special nature of
opDispatch is how you can define how to map any symbol to any
implementation without having to explicitly use strings. In fact,
opDispatch is slightly less powerful than such a method if the method
uses a runtime string for dispatch.
For example, in php, I can do this:
foo($var)
{
$obj->$var();
}
The equivalent in D would be:
foo(string var)
{
obj.opDispatch!(var)();
}
This I would consider to be true runtime-decided dispatch.
-Steve
As pointed out, ActionScript and JavaScript use foo.bar and foo["bar"]
interchangeably, so I believe we could do something similar.
I believe there is no real difference between d.foo and d.bar for
opDispatch (except that it could calculate string hash at compile time
for faster hast-table lookup), and it would just call a generic
run-time method anyway. As such, this method could be made visible to
everyone:
class Dynamic
{
// getter
@property Dynamic opDispatch(string prop) {
return this[prop];
}
// setter
@property void opDispatch(string prop)(Dynamic value) {
this[prop] = value;
}
ref Dynamic opIndex(string propName)
{
// do a hash-table lookup
}
Dynamic opCall(Args...)(Args args)
{
// do magic
}
}
This is a very nice example, I only see one minor problem with it: the
"do a hash table lookup" has to tentatively add an element if one
doesn't yet exist.
However, opDispatch is even less runtime-decided in this example (it can
always be inlined).
So essentially, opDispatch is just a syntax sugar. But it's very
important one, because not only it makes writing code easier, it would
allow using dynamic objects with generic algorithms.
Essentially you could say opDispatch is dynamic at compile time.
Runtime, not so much. But anything decided at compile time can be
forwarded to a runtime function.
You don't seem to have any idea what the term 'dynamic' means. From
http://en.wikipedia.org/wiki/Dynamic_programming_language
“Dynamic programming language is a term used broadly in computer science
to describe a class of high-level programming languages that execute at
runtime many common behaviors that other languages might perform during
compilation, if at all.”
From http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing
“A programming language is said to be dynamically typed, when the
majority of its type checking is performed at run-time as opposed to at
compile-time. In dynamic typing, types are associated with values not
variables.”
The dynamic quite clearly means something that happens at runtime. It's
not a compile time feature.
Well, it does seem to be rather novel in a statically typed, compiled
language. It blurs the boundary a bit, so it's not quite clear what
naming is appropriate. It enables the same syntax which dynamic
programming languages use at runtime. I'm not sure that the fact that it
occurs at compile-time rather than run-time is important. (Presumably, a
dynamic language is permitted to implement functionality at compile
time, if it can do so without affecting the semantics).
