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);
}
}
