Kris wrote:
> Er, that really doesn't work at all. Please ignore what I said a few minutes ago
> regarding this option (I really should get some sleep instead). 
> 
> The problem here is that, for the proposed static imports, everything must be
> fully-qualified with the /original import name/, and that's just plain awful for
> long import names. The "import as" allows one to give it a nice short name
> instead.

Alias also works fine for making substitutes for long, awkward names:

import x.y.mod;
alias x.y.mod t;

x.y.mod.foo();	// works
t.foo();	// also works


> And, I still think the selective-import is the superior solution anyway.

Semantically, it isn't any different. It would even be implemented internally using the 'alias' machinery.

kris wrote:
> Just for fun, how many folks here have hands-on experience with any of the following languages?
> 
> Algol
> Pascal
> BCPL
> Ada
> Modula
> Simula

Ada

Bruno Medeiros wrote:
> I must contested the proposed named by Walter. "static import" seems a pretty crappy name, there is nothing "static" about it. Do we have to recycle existing keywords? I'm not very much into this phobia of introducing new keywords. You didn't have a problem introducing "scope"... :P

Turns out, "scope" was a problem. It broke a lot of my code - a lot more than I'd anticipated.

On Sun, 09 Jul 2006 10:54:03 +1000, Walter Bright <newshound@digitalmars.com> wrote:


> Alias also works fine for making substitutes for long, awkward names:
>
> import x.y.mod;
> alias x.y.mod t;
>
> x.y.mod.foo();	// works
> t.foo();	// also works

Why not join the two ...

  import x.y.mod alias t;

  t.foo();

-- 
Derek Parnell
Melbourne, Australia

On Sun, 09 Jul 2006 11:12:07 +1000, Walter Bright <newshound@digitalmars.com> wrote:

> Bruno Medeiros wrote:
>> I must contested the proposed named by Walter. "static import" seems a pretty crappy name, there is nothing "static" about it. Do we have to recycle existing keywords? I'm not very much into this phobia of introducing new keywords. You didn't have a problem introducing "scope"... :P
>
> Turns out, "scope" was a problem. It broke a lot of my code - a lot more than I'd anticipated.

Hint: Using identifier names that have at least one upper case character in them reduces conflicts with D keywords.

-- 
Derek Parnell
Melbourne, Australia

Walter Bright wrote:
> Kris wrote:
>> Er, that really doesn't work at all. Please ignore what I said a few minutes ago
>> regarding this option (I really should get some sleep instead).
>> The problem here is that, for the proposed static imports, everything must be
>> fully-qualified with the /original import name/, and that's just plain awful for
>> long import names. The "import as" allows one to give it a nice short name
>> instead.
> 
> Alias also works fine for making substitutes for long, awkward names:
> 
> import x.y.mod;
> alias x.y.mod t;
> 
> x.y.mod.foo();    // works
> t.foo();    // also works

Yup.  'as' would just be a convenience and potentially add a slight bit of clarity.  Though I'll admit to sort of liking Kris' alternate interpretation where the alias prefix isn't optional.

>> And, I still think the selective-import is the superior solution anyway.
> 
> Semantically, it isn't any different. It would even be implemented internally using the 'alias' machinery.

    module A;

    void foo() {}
    void bar() {}

    module B;

    void bar() {}

    module main;

    import A.foo;
    import B.bar;

    foo();
    bar(); // unambiguous

So not strictly the same, unless the proposal also involved always using a namespace qualifier?


Sean

Derek Parnell wrote:
> On Sun, 09 Jul 2006 10:54:03 +1000, Walter Bright <newshound@digitalmars.com> wrote:
> 
> 
>> Alias also works fine for making substitutes for long, awkward names:
>>
>> import x.y.mod;
>> alias x.y.mod t;
>>
>> x.y.mod.foo();    // works
>> t.foo();    // also works
> 
> Why not join the two ...
> 
>   import x.y.mod alias t;
> 
>   t.foo();
> 

Perfect.

> --Derek Parnell
> Melbourne, Australia

Sean Kelly wrote:
> Walter Bright wrote:
> 
>> Kris wrote:
>>
>>> Er, that really doesn't work at all. Please ignore what I said a few minutes ago
>>> regarding this option (I really should get some sleep instead).
>>> The problem here is that, for the proposed static imports, everything must be
>>> fully-qualified with the /original import name/, and that's just plain awful for
>>> long import names. The "import as" allows one to give it a nice short name
>>> instead.
>>
>>
>> Alias also works fine for making substitutes for long, awkward names:
>>
>> import x.y.mod;
>> alias x.y.mod t;
>>
>> x.y.mod.foo();    // works
>> t.foo();    // also works
> 
> 
> Yup.  'as' would just be a convenience and potentially add a slight bit of clarity.  Though I'll admit to sort of liking Kris' alternate interpretation where the alias prefix isn't optional.
> 
>>> And, I still think the selective-import is the superior solution anyway.
>>
>>
>> Semantically, it isn't any different. It would even be implemented internally using the 'alias' machinery.
> 
> 
>     module A;
> 
>     void foo() {}
>     void bar() {}
> 
>     module B;
> 
>     void bar() {}
> 
>     module main;
> 
>     import A.foo;
>     import B.bar;
> 
>     foo();
>     bar(); // unambiguous
> 
> So not strictly the same, unless the proposal also involved always using a namespace qualifier?

I posted this proposal earlier, but I like it so much I'll repeat myself:

import B with bar;
bar(); // unambiguous

The point is you can list multiple names from the module without repeating the module name:

import MyModule with foo, baz;

And "with" is already a keyword.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

Kirk McDonald wrote:
> import B with bar;
> bar(); // unambiguous
> 
> The point is you can list multiple names from the module without repeating the module name:
> 
> import MyModule with foo, baz;
> 
> And "with" is already a keyword.
> 

To put this another way (forgive any errors in my syntax, I'm not used to it):

ImportDeclaration:
	import ModuleNameList ;

ModuleNameList:
	ModuleNameAliasWith
	ModuleNameAlias , ModuleNameList

ModuleNameAliasWith
	ModuleNameAlias
	ModuleNameAlias with IdentifierAliasList

ModuleNameAlias:
	ModuleName
	ModuleName alias Identifier

IdentifierAliasList:
	IdentifierAlias
	IdentifierAlias , IdentifierAliasList

IdentifierAlias:
	Identifier
	Identifier alias Identifier

Note that this means that as soon as "with" is used, you cannot specify any more modules in that import statement:

// Imports modules foo, bar, and baz, and aliases
// baz.a, baz.b, and baz.c
import foo, bar, baz with a, b, c;

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

In article <e8pk3b$26bo$1@digitaldaemon.com>, Walter Bright says...
>
>Kris wrote:
>> Er, that really doesn't work at all. Please ignore what I said a few minutes ago regarding this option (I really should get some sleep instead).
>> 
>> The problem here is that, for the proposed static imports, everything must be fully-qualified with the /original import name/, and that's just plain awful for long import names. The "import as" allows one to give it a nice short name instead.
>
>Alias also works fine for making substitutes for long, awkward names:
>
>import x.y.mod;
>alias x.y.mod t;
>
>x.y.mod.foo();	// works
>t.foo();	// also works
>
>
>> And, I still think the selective-import is the superior solution anyway.
>
>Semantically, it isn't any different. It would even be implemented internally using the 'alias' machinery.


Walter,

The use of "alias" still looks like a hack.  We know you've always been firm in your belief that "alias" is the way to do it.  I doubt that all these people would be discussing options here if they were satisfied with that solution (which has been around for a looong time).

We know it can be done with alias. Kris knows. We don't think it's good enough. That's why this whole topic is being wrangled.

So if you choose to make the internal machinery do it with alias, fine!  We just want something that's better, nicer, more professional looking! :) (please not "static import," though).

While I do agree that D would suffer if you followed the communities whim for every little feature suggested, yet I think you are far too independent minded most of the time.  The quote in your recent interview at Bitwise -- "D is going wherever the D community wants it to go" -- is really a farce.  D is going where /you/ want it to go, Walter.

And there's nothing wrong with admitting that.  I just think a honesty is important here.  This is your language.  You've made that very plain over the years, and most of us who have stuck around have accepted that. You strongly disfavour committees and bureaucracy, which is completely understandable; but, your over-protectiveness and fear of them may be doing the same sort of damage on the opposite end of the spectrum.

Don't take this wrong:  I'm very thankful about all you've done with D; I just get a little frustrated at how hard you are to convince of anything, a trait that may do well for you in some ways but probably hurts you so much more in other ways.

-JJR