Nick Sabalausky wrote:
"Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message
news:gsapl6$24e...@digitalmars.com...
Steven Schveighoffer wrote:
Sure, how do you know that the class actively chose it, or did not
actively choose it, or will *never* actively choose it simply by looking
at the statement?
You shouldn't worry about it as much as you shouldn't when you iterate a
built-in array vs. a user-defined range.
Would you like ranges that work very different from built-in arrays, and
everybody to special-case around that?
That's an inadequate comparison. We *can* make arrays and ranges usable in
the same way. But opDotExp cannot make dynamic calls usable in the same way
as static calls, because one of the rules of static method invokation is
that trying to call a non-existant function results in a compile-time error.
The best opDotExp can do it make dynamic calls *seem* the same which is
deceptive.
Au contraire, it's a very adequate comparison. We changed the language
to support ranges/arrays uniformly. Here, I'll paste your argument with
the appropriate changes:
====
But globals acting as members cannot make arrays usable in the same way
as user-defined types, because one of the rules of arrays is that trying
to call a non-existant member function on an array results in a
compile-time error. The best your rule can do it make nonmember calls
*seem* the same which is deceptive.
====
If you want static and dynamic calls to be really usable in the same way
(like iterating over a range vs array), then there's only two possibilities:
1. Make attempts to invokation a non-existant static function a runtime
error (obviously a bad idea).
or
2. Provide a *secondary* syntax to invoke a method that works for both
static and dynamic. Such as through a reflection api:
traits(new Foo()).invokeMethod("bar");
If I want to write an algorithm that calls "bar" twice, it should be:
void twix(T)(T value)
{
value.bar();
value.bar();
}
NOT
void twix(T)(T value)
{
static if (isDynamicType!T)
{
value.invokeMethod("bar");
value.invokeMethod("bar");
}
else
{
value.bar();
value.bar();
}
}
Please at least acknowledge that you are in receipt of this argument.
We are discussing a language extension. That language extension will
allow a type to choose flexibility in defining methods dynamically,
while being otherwise integrated syntactically with the current values.
This has advantages, but also alters the expectations.
Andrei
