Steven Schveighoffer wrote:
On Fri, 17 Apr 2009 18:01:51 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
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.
====
Calling global functions as if they were array members does not subvert
the type system. It is not even close to the same level of danger that
this is.
It's also far away from the same level of opportunity.
I'm all for expanding runtime introspection that remains within the type
system, I'm even for adding some possibility to create dynamically
dispatched functions, as long as those functions are called differently
from normal functions.
I think you would agree that one of the main roles of the compiler is to
prevent you from making mistakes before it even gets to runtime.
Without knowing which calls the compiler checked and which ones it
didn't, I can't know where to spend time scrutinizing.
Of course I agree. The thing is, if you decide to use a dynamic type,
then it will become like a dynamic type.
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.
I think Nick's point number 2 is that you would have to write the above as:
void twix(T)(T value)
{
value.invokeMethod("bar");
value.invokeMethod("bar");
}
which would work whether bar was dynamically or statically defined.
And will uglify and pessimize all code for the benefit of the few.
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.
As long as it identifies what can be dynamic and what cannot. I can't
imagine Walter will go for this with his strict view of hijacking.
You will be surprised.
Andrei
