Suggestion: module opcall

[Nick Sabalausky]

----- Original Message ----- 
From: "Bill Baxter" <wbaxter at gmail.com>
Newsgroups: digitalmars.D
To: "digitalmars.D" <digitalmars-d at puremagic.com>
Sent: Thursday, January 08, 2009 8:49 PM
Subject: Re: Suggestion: module opcall


> On Fri, Jan 9, 2009 at 10:23 AM, bearophile <bearophileHUGS at lycos.com>
> 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.)