On Mon, 04 May 2009 23:52:56 +0400, bearophile <bearophileh...@lycos.com> wrote:
Sometimes I rename recursive functions, or I duplicate and modify them,
and they stop working because inside them there's one or more copy of
their old name, so for example they recurse to their old name.
So inside a function I'd like to have a standard name to call the
function itself, useful for recursivity.
(If you have two or more recursive functions that call each other this
idea can't be used, but I think such situations are uncommon enough to
not deserve help from the language).
I have just discussed this in the Python newsgroup too:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/d265da85d4b70eaf#
I use more recursivity in D than in Python, because Python has troubles
with it.
In future in D2 you may use:
int ANUGLYNAME(int n) {
if (n <= 1)
return 1;
else
mixin(__FUNCTION__ ~ "(n - 1) * n");
}
But you can't use __FUNCTION__ into a delegate/function pointer/lambda
because the name isn't available, and it's a bit ugly syntax anyway...
This looks a bit better:
int ANUGLYNAME(int n) {
if (n <= 1)
return 1;
else
__self(n - 1) * n;
}
Other syntaxes are possible.
__self is a way to denote the pointer/delegate of the function currently
being run, so I think the compiler is always able to that, for delegate/
function pointers/ lambdas/ methods/ virtual methods/ opCalls too.
Bye,
bearophile
It was proposed awhile ago:
http://www.digitalmars.com/d/archives/digitalmars/D/FUNCTION_84985.html
Andrei's respond:
"I think instead of __FUNCTION__ we'll define a much more comprehensive
static reflection facility."
"You will have it as a human readable identifier too. The problem with
__FUNCTION__, __CLASS__ etc. is that the list of ad-hoc names (what
happened to __STRUCT__, __MODULE__ et al?) can go forever."
"D2 will have reflection. (Walter doesn't know yet. He thinks D3 will
have reflection.) It will be compile-time reflection because only
run-time reflection only is missing the point."
"This is a long discussion, but in brief any runtime reflection engine
needs some sort of compile-time metadata infrastructure. Some languages
don't make that accessible within the language itself. Runtime
reflection has been explored extensively, its possibilities and
limitations are pretty well understood, I hardly smothered a yawn
reading all you wrote. Compile-time reflection is much less understood
and hides many more exciting possibilities. With the advances in
compiler technology implemented by Walter, we have a chance to tackle
reflection in a systematic manner."
