On 02/06/2011 16:28, KennyTM~ wrote:
On Jun 2, 11 22:47, Bruno Medeiros wrote:
On 30/05/2011 18:41, KennyTM~ wrote:
On May 31, 11 00:59, Jose Armando Garcia wrote:
[snip]
Walter, what do you think about adding __MODULE__ to the language? It
will work similar to __FILE__ and __LINE__ but instead get replaced by
the name of the module. This would be really useful for std.log's
verbosity filtering feature.
I can send a pull request once I am familiar with dmd's code.
Thanks,
-Jose
I'd recommend making __MODULE__ return the actual module object instead
of the module name, in case anybody wants to implement it. The latter
can be easily got by __MODULE__.stringof[7..$] or parsing
std.traits.mangledName!__MODULE__ if you need the fully-qualified name,
but the reverse is not true.
Moreover, making __MODULE__ a true module object allows a global scope
be passed around implicitly, e.g. currently you need to write
int f(int x) { return x*x-2; }
void main() {
auto m = map!((y){ return f(y)+1; })([1,6,8]);
// ^^^^^^^^^^^^^^^^^^^^^ ugly
but with __MODULE__ it is possible to reduce the syntactic noise:
auto m = map!"f(a)+1"([1,6,8]);
by declaring std.functional.unaryFun as
template unaryFun(alias f, ....., alias mod=__MODULE__) {
...
with (mod) {
mixin(f);
}
...
Why do we need __MODULE__ at all for that, a new key does not seems
necessary. Instead of "__MODULE__.stringof[7..$]" there is
".stringof[7..$]" which works already. As for accessing the module scope
itself, perhaps we could use ".this" as a syntax.
__MODULE__ is evaluated at instantiation site, like __FILE__ and
__LINE__, while .stringof is evaluated at definition site.
Ah, I see what you mean, when they are used as default arguments in
functions and templates, right? Didn't recall that was the case.
--
Bruno Medeiros - Software Engineer
