In article <optcjo9wna23k2f5@nrage>, Regan Heath says...
>
>On Tue, 11 Jul 2006 23:46:03 +0300, Jari-Matti MäkelE <jmjmak@utu.fi.invalid> wrote:
>> Regan Heath wrote:
>>> On Mon, 10 Jul 2006 05:37:41 +0000 (UTC), Tyro <Tyro_member@pathlink.com> wrote:
>>>> In article <optcgh6iaa23k2f5@nrage>, Regan Heath says...
>>>>>
>>>>> --[a.d]--
>>>>> import std.stdio;
>>>>> template foo { writefln("Hello World"); }
>>>>>
>>>>> --[b.d]--
>>>>> import std.stdio as bar;
>>>>> import a;
>>>>>
>>>>> void main() {
>>>>>   mixin foo;
>>>>> }
>>>>>
>>>>> I accidently called the template and import named scope the same thing.
>>>>>
>>>>> Regan
>>>>
>>>> In this case I assume that you are concerned with conflicts that may be generated between both imports of std.stdio in [a.d] and [b.d].
>>>
>>> Nope. In a.d you can call "writefln" but in b.d you must call
>>> "bar.writefln", plain old writefln will fail, right?
>>> So, what does this mean for mixins?
>>
>> Are you referring to the existing functionality (sans implementation bugs) or some specific proposal here.
>
>The proposal to import a module into a namespace. In this case "std.stdio" into "bar", meaning "writefln" does not exist but "bar.writefln" does.
>
>> IMO Tyro is right and plain old
>> writefln definitely shouldn't fail here. It should only fail when
>> std.stdio has been imported privately in file a.d. But if import were
>> private by default, then the compiler would say 'b.d(5): undefined
>> identifier writefln'.
>
>All I was really asking was...
>
>If module a.d imports "std.stdio" into the current namespace, then calls "writefln" in a template which is then mixed into another source file b.d, which imports "std.stdio" into a named namespace "bar", can that template call "writefln"?
>
>I suspect the answer would have to be "no". After all the mixin is mixed into the scope of b.d, it doesn't exist in the scope of a.d where "writefln" is valid.
>
>All I was really trying to do was raise this as an issue which would occur (and need a solution) if we had import into namespace 'x'.
>
>Regan
>

As I understand it, anything imported into the global scope (public import) of [a.d] will be available in any other module that imports it. Unless of course, Walter has finally decided to do the right thing and make imports private by default! In the event he has, then the correct and desired result (for me anyway) would be to get an error message stating: "writefln, mixed in on ln#, is undefine".

Just in case that doesn't make any sense, let me try it a another way: By importing [a.d] into [b.d] and by virtue of std.stdio being publicly imported into [a.d], you have also imported std.stdio into [b.d]. If imports are made private by default or if explicitly imported privately, then an error message similar to the one suggested earlier is expected.

I hope that makes sense!

Andrew C. Edwards

Tyro wrote:
> Just in case that doesn't make any sense, let me try it a another way: By importing [a.d] into [b.d] and by virtue of std.stdio being publicly imported into [a.d], you have also imported std.stdio into [b.d]. If imports are made private by default or if explicitly imported privately, then an error message similar to the one suggested earlier is expected.
Exactly.

As a side note: I just installed dmd 0.162 and it seems imports have been finally fixed. Now private imports and private members really are private, yay! This means that private members are not accessible, but they are visible to the unprivileged modules. Private imports are not visible nor accessible. Yes, this is how it really should work. Even diamond shaped import constructions work according to my simple test suite. Simply excellent! Thank you Walter!

-- 
Jari-Matti

On Wed, 12 Jul 2006 02:37:00 +0300, Jari-Matti Mäkelä wrote:

> Tyro wrote:
>> Just in case that doesn't make any sense, let me try it a another way: By importing [a.d] into [b.d] and by virtue of std.stdio being publicly imported into [a.d], you have also imported std.stdio into [b.d]. If imports are made private by default or if explicitly imported privately, then an error message similar to the one suggested earlier is expected.
> Exactly.
> 
> As a side note: I just installed dmd 0.162 and it seems imports have been finally fixed. Now private imports and private members really are private, yay! This means that private members are not accessible, but they are visible to the unprivileged modules. Private imports are not visible nor accessible. Yes, this is how it really should work. Even diamond shaped import constructions work according to my simple test suite. Simply excellent! Thank you Walter!

Almost anyway... (1) FQN usage incorrectly overrides 'private'.

Consider these five files ...

 // ---- aaa.d -----
 private int foo() { return 1; }

 // ---- bbb.d ----
 private import aaa;
 private int bar() { return 2; }

 // ---- ccc.d ----
 private int foo() { return 3; }

 // ---- ddd.d ----
 private import ccc;
 private int bar() { return 4; }

 // ---- eee.d ----
 import bbb;
 import ddd;
 import std.stdio;
 void main()
 {
    writefln("aaa.foo %s", aaa.foo());
    writefln("bbb.bar %s", bbb.bar());
    writefln("ccc.foo %s", ccc.foo());
    writefln("ddd.bar %s", ddd.bar());
 }

This compiles fine and when run I get ...

 aaa.foo 1
 bbb.bar 2
 ccc.foo 3
 ddd.bar 4

(2) The error message given when not using FQN is not very helpful.

Change the eee.d file to ...
 // ---- eee.d ----
 import bbb;
 import ddd;
 import std.stdio;
 void main()
 {
    writefln("bar %s", bar());
 }

And the compiler gives this message ...

 bbb.d(3): function bbb.bar conflicts with ddd.bar at ddd.d(3)
 eee.d: module eee bbb.bar is private

The problems with this message are that it doesn't give the line number in eee.d that triggered the message, and that it exposes 'private' stuff to the coder. A better message might be along the lines of ...

 eee.d(6): No accessible function 'bar' was found.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
12/07/2006 10:02:30 AM

On Wed, 12 Jul 2006 02:20:06 +0300, Jari-Matti Mäkelä <jmjmak@utu.fi.invalid> wrote:
> Regan Heath wrote:
>> On Tue, 11 Jul 2006 23:46:03 +0300, Jari-Matti Mäkelä
>> <jmjmak@utu.fi.invalid> wrote:
>>> Regan Heath wrote:
>>>> On Mon, 10 Jul 2006 05:37:41 +0000 (UTC), Tyro
>>>> <Tyro_member@pathlink.com> wrote:
>>>>> In article <optcgh6iaa23k2f5@nrage>, Regan Heath says...
>>>>>>
>>>>>> --[a.d]--
>>>>>> import std.stdio;
>>>>>> template foo { writefln("Hello World"); }
>>>>>>
>>>>>> --[b.d]--
>>>>>> import std.stdio as bar;
>>>>>> import a;
>>>>>>
>>>>>> void main() {
>>>>>>   mixin foo;
>>>>>> }
>>>>>>
>>>>>> I accidently called the template and import named scope the same
>>>>>> thing.
>>>>>>
>>>>>> Regan
>>>>>
>>>>> In this case I assume that you are concerned with conflicts that may be
>>>>> generated between both imports of std.stdio in [a.d] and [b.d].
>>>>
>>>> Nope. In a.d you can call "writefln" but in b.d you must call
>>>> "bar.writefln", plain old writefln will fail, right?
>>>> So, what does this mean for mixins?
>>>
>>> Are you referring to the existing functionality (sans implementation
>>> bugs) or some specific proposal here.
>>
>> The proposal to import a module into a namespace. In this case
>> "std.stdio" into "bar", meaning "writefln" does not exist but
>> "bar.writefln" does.
>
> But if you import both:
>  import std.stdio as bar;
>  import std.stdio; (it's a public import, isn't it)
>
> which (AFAIK) is exactly the same as
>
> module a:
>  import std.stdio;
> module b:
>  import a;
>  import std.stdio as bar;
>
> Doesn't that mean that you can use both:
> [1]  writefln(...);
> and
> [2]  bar.writefln(...);
> ?
>
> Which one of the proposals makes it illegal to call [1] in module b?

Ahh, I've done it again. That'll teach me for not at least coding my little example up. I was assuming the import was private.. again.. (which I think they should be, by default)

>> All I was really asking was...
>>
>> If module a.d imports "std.stdio" into the current namespace, then calls
>> "writefln" in a template which is then mixed into another source file
>> b.d, which imports "std.stdio" into a named namespace "bar", can that
>> template call "writefln"?
>>
>> I suspect the answer would have to be "no".
>
> Um, I don't think so. The only thing that could make it illegal is that
>  template foo { writefln("Hello World"); }
> isn't valid D. Maybe it should be
>  template foo { void hello() { writefln("Hello World"); } }
> ?

No.. I was mistakenly assuming I could put _anything_ into a template, including calls to writefln into 'main' .. turns out you can only put stuff you could declare at the global scope in there. variables, functions, etc. not calls to function. My bad.

>> After all the mixin is mixed
>> into the scope of b.d, it doesn't exist in the scope of a.d where
>> "writefln" is valid.
>
> Correct. From http://www.digitalmars.com/d/mixin.html: "Unlike a
> template instantiation, a template mixin's body is evaluated within the
> scope where the mixin appears, not where the template declaration is
> defined. It is analogous to cutting and pasting the body of the template
> into the location of the mixin."
>
>> All I was really trying to do was raise this as an issue which would
>> occur (and need a solution) if we had import into namespace 'x'.
>
> I think a more interesting use case would be to use real templates
> (they're instantiated in module a) instead of mixins and module a that
> is using a import statement that only imports some of the std.stdio
> members. That might even cause some trouble?

Example?

Regan

On Tue, 11 Jul 2006 23:10:38 +0000 (UTC), Tyro <Tyro_member@pathlink.com> wrote:
> In article <optcjo9wna23k2f5@nrage>, Regan Heath says...
>>
>> On Tue, 11 Jul 2006 23:46:03 +0300, Jari-Matti Mäkel�E
>> <jmjmak@utu.fi.invalid> wrote:
>>> Regan Heath wrote:
>>>> On Mon, 10 Jul 2006 05:37:41 +0000 (UTC), Tyro
>>>> <Tyro_member@pathlink.com> wrote:
>>>>> In article <optcgh6iaa23k2f5@nrage>, Regan Heath says...
>>>>>>
>>>>>> --[a.d]--
>>>>>> import std.stdio;
>>>>>> template foo { writefln("Hello World"); }
>>>>>>
>>>>>> --[b.d]--
>>>>>> import std.stdio as bar;
>>>>>> import a;
>>>>>>
>>>>>> void main() {
>>>>>>   mixin foo;
>>>>>> }
>>>>>>
>>>>>> I accidently called the template and import named scope the same
>>>>>> thing.
>>>>>>
>>>>>> Regan
>>>>>
>>>>> In this case I assume that you are concerned with conflicts that may be
>>>>> generated between both imports of std.stdio in [a.d] and [b.d].
>>>>
>>>> Nope. In a.d you can call "writefln" but in b.d you must call
>>>> "bar.writefln", plain old writefln will fail, right?
>>>> So, what does this mean for mixins?
>>>
>>> Are you referring to the existing functionality (sans implementation
>>> bugs) or some specific proposal here.
>>
>> The proposal to import a module into a namespace. In this case "std.stdio"
>> into "bar", meaning "writefln" does not exist but "bar.writefln" does.
>>
>>> IMO Tyro is right and plain old
>>> writefln definitely shouldn't fail here. It should only fail when
>>> std.stdio has been imported privately in file a.d. But if import were
>>> private by default, then the compiler would say 'b.d(5): undefined
>>> identifier writefln'.
>>
>> All I was really asking was...
>>
>> If module a.d imports "std.stdio" into the current namespace, then calls
>> "writefln" in a template which is then mixed into another source file b.d,
>> which imports "std.stdio" into a named namespace "bar", can that template
>> call "writefln"?
>>
>> I suspect the answer would have to be "no". After all the mixin is mixed
>> into the scope of b.d, it doesn't exist in the scope of a.d where
>> "writefln" is valid.
>>
>> All I was really trying to do was raise this as an issue which would occur
>> (and need a solution) if we had import into namespace 'x'.
>>
>> Regan
>>
>
> As I understand it, anything imported into the global scope (public import) of
> [a.d] will be available in any other module that imports it. Unless of course,
> Walter has finally decided to do the right thing and make imports private by
> default! In the event he has, then the correct and desired result (for me
> anyway) would be to get an error message stating: "writefln, mixed in on ln#, is
> undefine".
>
> Just in case that doesn't make any sense, let me try it a another way: By
> importing [a.d] into [b.d] and by virtue of std.stdio being publicly imported
> into [a.d], you have also imported std.stdio into [b.d]. If imports are made
> private by default or if explicitly imported privately, then an error message
> similar to the one suggested earlier is expected.
>
> I hope that makes sense!

Yeah, I was assuming imports were private .. again .. I really wish they were.

Regan

Derek Parnell wrote:
> On Wed, 12 Jul 2006 02:37:00 +0300, Jari-Matti Mäkelä wrote:
>> As a side note: I just installed dmd 0.162 and it seems imports have been finally fixed. Now private imports and private members really are private, yay! This means that private members are not accessible, but they are visible to the unprivileged modules. Private imports are not visible nor accessible. Yes, this is how it really should work. Even diamond shaped import constructions work according to my simple test suite. Simply excellent! Thank you Walter!
> 
> Almost anyway... (1) FQN usage incorrectly overrides 'private'.
> 
Yeah, I noticed it after playing with imports for a while.
> 
> (2) The error message given when not using FQN is not very helpful.

No, but it finally works. A step in the right direction. ;)

> 
> Change the eee.d file to ...
>  // ---- eee.d ----
>  import bbb;
>  import ddd;
>  import std.stdio;
>  void main()
>  {
>     writefln("bar %s", bar());
>  }
> 
> And the compiler gives this message ...
> 
>  bbb.d(3): function bbb.bar conflicts with ddd.bar at ddd.d(3)
>  eee.d: module eee bbb.bar is private
> 
> The problems with this message are that it doesn't give the line number in eee.d that triggered the message, and that it exposes 'private' stuff to the coder.

Yeah, this is a bit funny one. :)

> A better message might be along the lines of ...
> 
>  eee.d(6): No accessible function 'bar' was found.

Yes. Personally I would also like to know possible matches to the function call. Usually I start with everything as private as possible and widen the visibility, when problems like this occur.

-- 
Jari-Matti

mån 2006-07-10 klockan 18:26 +0000 skrev jcc7:
> In article <e8u2s1$1li1$1@digitaldaemon.com>, Chris Nicholson-Sauls says...
> >
> >jcc7 wrote:
> >> In article <optcf2eoqc23k2f5@nrage>, Regan Heath says...
> >> 
> >>>Sub-thread for ideas.
> >> 
> >> 
> >> I'm not thrilled about the prospect of reusing static for yet another purpose, but I don't think that we need to add "from" or "as" to the keyword list either.
> >> 
> >> Instead of "import fooTooLong.reallyTooLong as fooShort;"
> >> 
> >> we could re-use an operator:
> >> "import fooTooLong.reallyTooLong = fooShort;"
> >> 
> >> I like it, but it could just be me.
> >
> >I think its a pretty neat idea, actually.  Although, maybe it should be the colon instead?
> 
> I thought about colon, but people will probably want to do things like this and I think the colon meaning could get confusing:
> 
> With equal symbol...
> 
> public:
> import fooTooLong.reallyTooLong = fooShort;
> import fooTooLong.reallyTooLong2 = fooShort2;
> 
> 
> With colon symbol...
> 
> public:
> import fooTooLong.reallyTooLong : fooShort;
> import fooTooLong.reallyTooLong2 : fooShort2;

perhaps something like this:

import fooTooLong {
	reallyTooLong: tooShort,    /* alias */
	reallyTooLong2: tooShort2,  /* alias 2
	notReallyTooLongAtAll       /* No alias */
}

to make several aliases from the same module? My 2c.

/Anders

Anders Runesson wrote:
> mån 2006-07-10 klockan 18:26 +0000 skrev jcc7:
> 
>>In article <e8u2s1$1li1$1@digitaldaemon.com>, Chris Nicholson-Sauls says...
>>
>>>jcc7 wrote:
>>>
>>>>In article <optcf2eoqc23k2f5@nrage>, Regan Heath says...
>>>>
>>>>
>>>>>Sub-thread for ideas.
>>>>
>>>>
>>>>I'm not thrilled about the prospect of reusing static for yet another purpose,
>>>>but I don't think that we need to add "from" or "as" to the keyword list either.
>>>>
>>>>Instead of "import fooTooLong.reallyTooLong as fooShort;"
>>>>
>>>>we could re-use an operator:
>>>>"import fooTooLong.reallyTooLong = fooShort;"
>>>>
>>>>I like it, but it could just be me.
>>>
>>>I think its a pretty neat idea, actually.  Although, maybe it should be the colon instead?
>>
>>I thought about colon, but people will probably want to do things like this and
>>I think the colon meaning could get confusing:
>>
>>With equal symbol...
>>
>>public:
>>import fooTooLong.reallyTooLong = fooShort;
>>import fooTooLong.reallyTooLong2 = fooShort2;
>>
>>
>>With colon symbol...
>>
>>public:
>>import fooTooLong.reallyTooLong : fooShort;
>>import fooTooLong.reallyTooLong2 : fooShort2;
> 
> 
> perhaps something like this: 
> 
> import fooTooLong {
> 	reallyTooLong: tooShort,    /* alias */
> 	reallyTooLong2: tooShort2,  /* alias 2
> 	notReallyTooLongAtAll       /* No alias */
> }
> 
> to make several aliases from the same module? My 2c.
> 
> /Anders
> 

I was thinking about that kind of thing my self. Seems logical. Some variations might be considered.

drop the import all together, (we aren't really importing "fooTooLong" after all, just some stuff in it):

with(fooTooLong)
{
   alias reallyTooLong tooShort;    /* alias */
   alias reallyTooLong2 tooShort2;  /* alias 2 */
   alias notReallyTooLongAtAll notReallyTooLongAtAll; /* No alias */
}

(only "with" at global scope so should parse)

Some hybrid of the two might look nice also.

In article <e938po$1cn1$1@digitaldaemon.com>, BCS says...
>
>Anders Runesson wrote:
>> mån 2006-07-10 klockan 18:26 +0000 skrev jcc7:
>> 
>>>In article <e8u2s1$1li1$1@digitaldaemon.com>, Chris Nicholson-Sauls says...
>>>
>>>>jcc7 wrote:
>>>>
>>>>>In article <optcf2eoqc23k2f5@nrage>, Regan Heath says...
>>>>>
>>>>>
>>>>>>Sub-thread for ideas.
>>>>>
>>>>>
>>>>>I'm not thrilled about the prospect of reusing static for yet another purpose, but I don't think that we need to add "from" or "as" to the keyword list either.
>>>>>
>>>>>Instead of "import fooTooLong.reallyTooLong as fooShort;"
>>>>>
>>>>>we could re-use an operator:
>>>>>"import fooTooLong.reallyTooLong = fooShort;"
>>>>>
>>>>>I like it, but it could just be me.
>>>>
>>>>I think its a pretty neat idea, actually.  Although, maybe it should be the colon instead?
>>>
>>>I thought about colon, but people will probably want to do things like this and I think the colon meaning could get confusing:
>>>
>>>With equal symbol...
>>>
>>>public:
>>>import fooTooLong.reallyTooLong = fooShort;
>>>import fooTooLong.reallyTooLong2 = fooShort2;
>>>
>>>
>>>With colon symbol...
>>>
>>>public:
>>>import fooTooLong.reallyTooLong : fooShort;
>>>import fooTooLong.reallyTooLong2 : fooShort2;
>> 
>> 
>> perhaps something like this:
>> 
>> import fooTooLong {
>> 	reallyTooLong: tooShort,    /* alias */
>> 	reallyTooLong2: tooShort2,  /* alias 2
>> 	notReallyTooLongAtAll       /* No alias */
>> }
>> 
>> to make several aliases from the same module? My 2c.
>> 
>> /Anders
>> 
>
>I was thinking about that kind of thing my self. Seems logical. Some variations might be considered.
>
>drop the import all together, (we aren't really importing "fooTooLong" after all, just some stuff in it):
>
>with(fooTooLong)
>{
>    alias reallyTooLong tooShort;    /* alias */
>    alias reallyTooLong2 tooShort2;  /* alias 2 */
>    alias notReallyTooLongAtAll notReallyTooLongAtAll; /* No alias */
>}
>
>(only "with" at global scope so should parse)
>
>Some hybrid of the two might look nice also.

I'm just not a big fan of using with for this since it seems like importing to me.

"with(module fooTooLong)" would be somewhat better, but I think "import" should be there. How about this?

# import select fooTooLong
# {
#    alias reallyTooLong tooShort;    /* alias */
#    alias reallyTooLong2 tooShort2;  /* alias 2 */
#    alias notReallyTooLongAtAll notReallyTooLongAtAll; /* No alias */
# }

or if you just want to import one it'd be something like this:

import select std.string.replace alias replace;

or maybe even this if it's not being renamed...

import select std.string.replace;

I think there's a really good syntax in here somewhere. I'm just not sure what it is yet...

jcc7

jcc7 wrote:
> 
> 
> I'm just not a big fan of using with for this since it seems like importing to
> me.
> 
> "with(module fooTooLong)" would be somewhat better, but I think "import" should
> be there. How about this?
> 
> # import select fooTooLong
> # {
> #    alias reallyTooLong tooShort;    /* alias */
> #    alias reallyTooLong2 tooShort2;  /* alias 2 */
> #    alias notReallyTooLongAtAll notReallyTooLongAtAll; /* No alias */
> # }
> 
> or if you just want to import one it'd be something like this:
> 
> import select std.string.replace alias replace;
> 
> or maybe even this if it's not being renamed...
> 
> import select std.string.replace;
> 
> I think there's a really good syntax in here somewhere. I'm just not sure what
> it is yet...
> 
> jcc7

Yeah, that "with" doesn't look to good. OTOH that "select" looks kind of funny also. I think just switching to the "alias <name> [<name>];" syntax would be best. IIRC all {} block use ";" as a separator, so it would be more consistent than a comma separated list.