On Sun, 19 Apr 2009 10:42:19 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Sun, 19 Apr 2009 18:26:11 +0400, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Sun, 19 Apr 2009 06:26:57 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Sun, 19 Apr 2009 05:40:32 +0400, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Sat, 18 Apr 2009 21:10:27 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Adam Burton wrote:
Andrei Alexandrescu wrote:
What about using something like '->' for dynamic calls instead of
'.'?
That's absolutely useless. If I have to write anything different
from
"." I might as well write "bloodyMaryBloodyMaryBloodyMary".
Andrei
You could even write 'noodles' but that doesn't really give me a
reason as to why it's absolutely useless. Please clarify, I thought
it seemed like a reasonable idea, if it isn't I would like to know
why.
I apologize for the snapping. There's no excuse really, but let me
mention that this thread has been particularly meandering.
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.
Hm... the thought just occurred to me.
At what time are you going to use opDotExp so an entity be used in an
algorithm rather than actually defining the functions directly? For
example, if you want to make a class/struct a range, why not just
define the functions directly? It seems odd to define them using
opDotExp.
Variant variantRange = someRange();
foreach (element; variantRange) {
// ...
}
Variant forwards all the front/back/etc methods to an underlying range.
Doesn't the current opDot solution do this? Forwarding all calls to a
certain member is not a really compelling argument for changing opDot
to allow dynamic method names.
-Steve
opDot is reprecated (use alias this instead) and will be eventually
removed.
But "alias this" is quite unsafe because it exposes the inner data
(which is supposed to be hidden in some case, think of reference
counting wrapper - you never want to give raw access to an underlying
data).
Besides, there are is a use-cases that you can't implement in a way
other than opDotExp. For example, add some logging or profiling:
struct Profile(T)
{
private T inner;
auto opDotExp(string name, T...)(T args)
{
profiler.enter(name);
scope(exit) profiler.leave();
return <forward a call to 'inner' - how one would do
this?>(args);
}
}
Yes, there are many things that opDotExp can do that opDot or alias this
(which is essentially opDot without any code). Hooking every function
call on a type seems to be one of the two killer use cases of this feature
(the other being defining a large range of functions from which only a
small number need to exist). But call forwarding seems not to be one of
them. There are better ways to simply forward a call (such as in your
variant example).
I'm pretty convinced that this is a useful feature, I still have qualms
about how it's really easy to define a runtime black hole where the
compiler happily compiles empty functions that do nothing instead of
complaining about calling a function that does not exist.
Also, I don't think the requirement for this feature needs to be for the
arguments to be templated, it should be sufficient to have a single string
template argument. This way, you can overload opDotExp functions via
argument lists.
And BTW, the answer to your question above I think:
mixin("return inner."~name~"(args)");
Andrei demonstrated this usage in his Pascalize example.
-Steve
