----- Original Message ----- From: "Bill Baxter" <[email protected]> Newsgroups: digitalmars.D To: "digitalmars.D" <[email protected]> Sent: Thursday, January 08, 2009 8:49 PM Subject: Re: Suggestion: module opcall
> On Fri, Jan 9, 2009 at 10:23 AM, bearophile <[email protected]> > wrote: >> Bill Baxter: >> >>>I think this problem you refer to only applies to modules without package >>>names. I.e. "module Foo" containing "class Foo". Things seem to work ok >>>if you have "module x.Foo" with "class Foo" inside.< >> >> Right. But why settle with a half-backed module system when there are >> more logic ways to design it? :-) >> >> >>> So you are saying you want this to be an error? >>> >>> import std.string; >>> void foo() { >>> std.string.format("hi"); // error no such symbol "std.string" >>> format("hi"); // ok >>> } >> >> >> The following examples show what I mean: >> >> import std.string; >> void foo() { >> std.string.format("hi"); // OK, "std.string" name exists in the >> current scope. >> format("hi"); // Error, "format" name is absent. >> } > > Ok. You mean like Python. I guess people here have bullied you into > stop using that phrase. :-) > My apologies for that ;-) > That would be fine by me. I'm also a big supporter of static import by > default. > > But I think it still doesn't solve the Stdout.Stdout annoyance does it? > > >>>auto x = new Foo; // Foo.Foo should not be needed if class Foo is the >>>only thing inside Foo.< >> >> That's a special casing, it may look handy, but it may also lead to >> troubles later. So I think it's better to keep things tidy, and avoid >> that. D allows enough things (renamed imports, alias, and selective >> imports) to solve such problems already. > > If you think so, then you should argue for removal of the special case > stuff for templates too. On the other hand, if it worked for modules > templates and classes, then would it be all that much of a special > case? > >>> template AReallyLongTemplateNameIDontWannaTypeTwice(T) { >>> void this(T x) { } >>> } >> >> You can write that in D1 as: >> >> void aReallyLongTemplateNameIDontWannaTypeTwice(T)(T x) { >> } > > Ok, bad example. Try that for a template that defines a constant or an > alias. > > template AReallyLongTemplateNameIDontWannaTypeTwice(T) { > alias T[] ReallyLongTemplateNameIDontWannaTypeTwice; > } > I was just thinking earlier, it would be nice if could handle const templates just like we do class templates and function templates: --------------- // Before: template SomeCodeToMixin(alias name) { const char[] SomeCodeToMixin = "int "~name~";"; } // After: const char[] SomeCodeToMixin(alias name) = "int "~name~";"; --------------- Nice as that would be, it unfortunately still doesn't solve this (which I do a lot): --------------- template SomeCodeToMixin(alias a) { const char[] SomeCodeToMixin = "int "~a~";"; pragma(msg, "SomeCodeToMixin: "~SomeCodeToMixin); } --------------- For that (...deja vu?), I'd like to have: --------------- template SomeCodeToMixin(alias a) { const char[] this = "int "~a~";"; pragma(msg, this.nameof~": "~this); } --------------- Ditto on how good D's naming is for constructors/destructors. That was one of the early things that really impressed me. (I may have double-posted, sorry about that.)
