Hello Adam,
BCS wrote:
Hello Adam,
On Sat, Apr 18, 2009 at 06:10:27PM -0700, Andrei Alexandrescu wrote:
The point of using "." is not syntactic convenience as much as the
ability of the Dynamic structure to work out of the box with
algorithms that use the standard notation.
What if the dot remained exactly like it is now and the -> took
the place of the dot in the proposal; regular method calls when
possible and forwarded to opExtension (opDotExp needs a better name)
when that fails?
Thus your generic algorithm can use -> and work in all cases, and
the
dot operator remains the same as it is now.
Going the other way would be better; '.' works as Andrei wants and
'->' is an explicit, "don't use the dynamic stuff" invocation. If it
went the other way virtually all template code would end up needing
to use '->' for everything just in cases someone wants to pass in a
type that uses opDotExp.
Yea and that would be bad, since then as far as I am concerned you
have destroyed the purpose of templates. Seems to me templates and
dynamic calls are sorta there to solve the same problem, how do you
write code that is independent of type? Dynamic takes it to extreme
and makes the evaluation of methods (or public types variables I don't
see how that would be different) and leave it all to runtime which is
far more flexible but potentially has holes if the type doesn't meet
the requirements. Templates take a more conservative route by still
letting you write independent of type but then using the information
provided at call time it can still perform static code checks to make
sure the type meets its needs, making it a little more safe than
dynamic. However soon as you throw some dynamic calls into a template
the guarantees usually provided go out the window since the template
is letting that none existent member slip by.
I see your point but disagree. I see it more as a "what to do if the code
author doesn't have full API knowledge?" problem. Templates allow the author
of the consuming code to go with a "I'll just assume this can be done and
let the compiler check it" approach and the dynamic option allows the author
of the producer to go with a "Do whatever you want and if I didn't say what
to do with it use this code to figure it out" approach.
(In the above, you seeme to be working with the assumption of the non static
opDotExp form. I, BTW, see no use for it as it adds no new functionality
to D where as the static opDotExp(char[],T...)(T t) form adds a new ability)
[ the rest of the post dealt with implications of non-static forms of opDotExp
]