Re: init.e - standard library candidate
- Posted by petelomax Mar 16, 2013
- 1338 views
I suspect this is simply broken.
I find that I concur with your suspicion, but possibly for different reasons. So, what should routine_id() do? Should it use the scope where the routine is called, or the scope where the routine is defined? This only applies to routine_id(), since no other routine cares about scope in the same way when it is called.
...
Based on that, I would conclude that this is indeed broken, because routine_id() always defaults to the callers scope.
...
That said, I suspect that fixing routine_id() to work intelligently in what I contend is the most natural manner is probably very difficult, while working around this behavior is really easy.
...
However, altering routine_id() so it always uses the scope of the callee is not useful
This makes embedding a routine_id() call inside of a defaulted parameter unconditionally useless.
So, yes, maybe it is technically broken, but if it can't be fixed, then breaking it in this way is better than the alternative.
Thanks for the excellent and detailed reply.
I have figured it out now; the default expression is effectively parsed in the called context (that part I really misread), but evaluated in the callee context, which as you point out makes no difference except for routine_id().
FWIW, I plan (not particularly soon) in Phix to change routine_id to:
global function routine_id(string name, boolean use_callee_context=false) ... procedure x(integer rid=routine_id("something",true))
which would allow what I see as the required extra flexibility. The extra parameter would not be valid in top-level code.
Regards, Pete
