On Wed, 6 Apr 2005 01:42:39 +0000 (UTC), Ant <Ant_member@pathlink.com> wrote:
> In article <opsor5vxo123k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>
>> On Tue, 5 Apr 2005 22:02:54 +0000 (UTC), Ant <Ant_member@pathlink.com>
>> wrote:
>>> In article <13jkf6n6kcyyc$.178nuu0td92rz.dlg@40tude.net>, Derek Parnell
>>> says...
>>>>
>>>> On Tue, 5 Apr 2005 13:49:36 +0000 (UTC), Ant wrote:
>>>>
>>>>> In article <onmlfs8c47jq.1f9v4jwrf23xx.dlg@40tude.net>, Derek Parnell
>>>>> says...
>>>>>>
>>>>>
>>>>>> It has to do with the sequence that these modules are compiled in.
>>>>>> Try this
>>>>>> sequence instead ...
>>>>>>
>>>>> But we are not trying to find a workaround, we are halping Walter to
>>>>> correct what seems to be a bug on the compiler.
>>>>
>>>> (1) I wasn't suggesting a workaround, that was incidental.
>>>> (2) You might not be after a workaround, but somebody else might be.
>>>> (3) I was demonstrating that under different conditions, the issue has
>>>> different manifestations, and thus that fact might be useful in the
>>>> problem
>>>> determination.
>>>>
>>>> Sorry I made myself so obscure.
>>>
>>> It's probably my fault guys, I should have than you for the workaround.
>>
>> No worries Ant, I can understand your position, you don't want a
>> workaround you want the bug fixed. I would be the same.
>>
>> I suspect that finding a workaround can help Walter find the bug and if
>> the workaround is yucky enough convince him it is a bug that needs to be
>> fixed ASAP.
>>
>> Where you said:
>>> The imports are not going to be used outside of the class body.
>>> Why sould they be declared outside of the class body? makes no sence.
>>> I moved the import to the class body as a workaround for the
>>> "forward reference" nightmare, but it's clearly where they belong.
>>
>> I understand, but lets explore this a bit as in certain situations it
>> appears to make no difference to the outcome (except to highlight bugs as
>> it has done in this case)...
>>
>> --[main.d]--
>> import inside;
>> import outside;
>> void main() {}
>>
>> --[outside.d]--
>> private import other;
>> class A { ..use other.. }
>>
>> --[inside.d]--
>> class A {
>>   private import other;
>> }
>>
>> whether the import is inside or outside the class, makes no difference to
>> main.d (as it's a private import). As there is only 1 class "A" it makes
>> no difference in the modules either.
>>
>> Now, if the import was public, or there were 2 classes eg.
>>
>> --[now.d]--
>> import other;
>> class A {
>>   ..use other..
>> }
>> class B {
>>   ..dont use other..
>> }
>>
>> 1- main would be polluted with symbols from other.
>> 2- class B would be polluted with symbols from other.
>>
>> To solve #1 you place 'private' on the import.
>>
>> #2 has no solution, except to place the import in the class A.
>>
>> To me this pollution is acceptable as the pollution itself causes very
>> little adverse effect, it is possible to get collisions, if so, use alias.
>> The trade off I get is that later, if I add another class, or start to use
>> 'other' in B I don't have to move/copy my imports around the place.
>>
>> So there you have my 2c on imports within classes. I don't use them.
>>
>> Regan
>
> So you say "has no solution, expect...". That's no exception!
> that's the solution!

Yes.. that's what I meant. :) There are no other solutions AKA "workarounds"

> I would take my view a bit further and allow the full qualified
> import to be declared on the class header:
> class B : mylib.utils.A , mylib.utils.I {...}
> and so avoid any polution form any import.

Hmm.. not sure I like the "look" of that.

> This would be irrelevant to me if I could place one class per module
> and 'private' really worked on the import
> (does it work now? how is it tested? TK?)

I think it works. I imagine you can test it by doing a private import and trying to access a member of that module by importing the module with the private import. (what is TK?)

> The real problem is that Walter has the import thing very low on his
> priority list. That makes it very brittle and me very afraid...

Actually my impression is that Walter doesn't agree there is a problem with import.

My only problem with import is that I believe import should default to 'private'. I have to type "private" in front of just about all my imports, on the rare occasion where I am importing module specific (i.e. not std.string) public data (i.e. not just used internally to this module) do I leave the "private" off.

The argument that "everything else" is public so "import" should also be public is <impolite>*bollocks*</impolite>. "everything else" isn't the same as "import". apples and oranges. etc.

Regan

> with the  private import. (what is TK?)

Mr. Thomas Kuehne! the http://dstress.kuehne.cn/ guy.

Ant

On Wed, 06 Apr 2005 16:30:24 +1200, Regan Heath wrote:

> On Wed, 6 Apr 2005 01:42:39 +0000 (UTC), Ant <Ant_member@pathlink.com> wrote:
>> In article <opsor5vxo123k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>>
>>> On Tue, 5 Apr 2005 22:02:54 +0000 (UTC), Ant <Ant_member@pathlink.com>
>>> wrote:
>>>> In article <13jkf6n6kcyyc$.178nuu0td92rz.dlg@40tude.net>, Derek Parnell says...
>>>>>
>>>>> On Tue, 5 Apr 2005 13:49:36 +0000 (UTC), Ant wrote:
>>>>>
>>>>>> In article <onmlfs8c47jq.1f9v4jwrf23xx.dlg@40tude.net>, Derek Parnell says...
>>>>>>>
>>>>>>
>>>>>>> It has to do with the sequence that these modules are compiled in.
>>>>>>> Try this
>>>>>>> sequence instead ...
>>>>>>>
>>>>>> But we are not trying to find a workaround, we are halping Walter to correct what seems to be a bug on the compiler.
>>>>>
>>>>> (1) I wasn't suggesting a workaround, that was incidental.
>>>>> (2) You might not be after a workaround, but somebody else might be.
>>>>> (3) I was demonstrating that under different conditions, the issue has
>>>>> different manifestations, and thus that fact might be useful in the
>>>>> problem
>>>>> determination.
>>>>>
>>>>> Sorry I made myself so obscure.
>>>>
>>>> It's probably my fault guys, I should have than you for the workaround.
>>>
>>> No worries Ant, I can understand your position, you don't want a workaround you want the bug fixed. I would be the same.
>>>
>>> I suspect that finding a workaround can help Walter find the bug and if the workaround is yucky enough convince him it is a bug that needs to be fixed ASAP.
>>>
>>> Where you said:
>>>> The imports are not going to be used outside of the class body.
>>>> Why sould they be declared outside of the class body? makes no sence.
>>>> I moved the import to the class body as a workaround for the
>>>> "forward reference" nightmare, but it's clearly where they belong.
>>>
>>> I understand, but lets explore this a bit as in certain situations it
>>> appears to make no difference to the outcome (except to highlight bugs
>>> as
>>> it has done in this case)...
>>>
>>> --[main.d]--
>>> import inside;
>>> import outside;
>>> void main() {}
>>>
>>> --[outside.d]--
>>> private import other;
>>> class A { ..use other.. }
>>>
>>> --[inside.d]--
>>> class A {
>>>   private import other;
>>> }
>>>
>>> whether the import is inside or outside the class, makes no difference
>>> to
>>> main.d (as it's a private import). As there is only 1 class "A" it makes
>>> no difference in the modules either.
>>>
>>> Now, if the import was public, or there were 2 classes eg.
>>>
>>> --[now.d]--
>>> import other;
>>> class A {
>>>   ..use other..
>>> }
>>> class B {
>>>   ..dont use other..
>>> }
>>>
>>> 1- main would be polluted with symbols from other.
>>> 2- class B would be polluted with symbols from other.
>>>
>>> To solve #1 you place 'private' on the import.
>>>
>>> #2 has no solution, except to place the import in the class A.
>>>
>>> To me this pollution is acceptable as the pollution itself causes very
>>> little adverse effect, it is possible to get collisions, if so, use
>>> alias.
>>> The trade off I get is that later, if I add another class, or start to
>>> use
>>> 'other' in B I don't have to move/copy my imports around the place.
>>>
>>> So there you have my 2c on imports within classes. I don't use them.
>>>
>>> Regan
>>
>> So you say "has no solution, expect...". That's no exception! that's the solution!
> 
> Yes.. that's what I meant. :) There are no other solutions AKA "workarounds"
> 
>> I would take my view a bit further and allow the full qualified
>> import to be declared on the class header:
>> class B : mylib.utils.A , mylib.utils.I {...}
>> and so avoid any polution form any import.
> 
> Hmm.. not sure I like the "look" of that.
> 
>> This would be irrelevant to me if I could place one class per module
>> and 'private' really worked on the import
>> (does it work now? how is it tested? TK?)
> 
> I think it works. I imagine you can test it by doing a private import and trying to access a member of that module by importing the module with the private import. (what is TK?)
> 
>> The real problem is that Walter has the import thing very low on his priority list. That makes it very brittle and me very afraid...
> 
> Actually my impression is that Walter doesn't agree there is a problem with import.
> 
> My only problem with import is that I believe import should default to 'private'. I have to type "private" in front of just about all my imports, on the rare occasion where I am importing module specific (i.e. not std.string) public data (i.e. not just used internally to this module) do I leave the "private" off.
> 
> The argument that "everything else" is public so "import" should also be public is <impolite>*bollocks*</impolite>. "everything else" isn't the same as "import". apples and oranges. etc.
> 
Yes. I'm always using "private import" too. I can't see a good (useful) use for public imports yet. A public import is a bit impertinent by my thinking. It says "Oh by the way, when you use my module 'x', you must also be wanting to directly use the modules that 'x' uses too, so I'm doing you a favor by making them available for you.". Ahhhh...but what if I wasn't intending to use that stuff - now I've got namespace clashes that I'm forced to resolve. Thank you, but if I need any of that stuff I'll import it myself, okay?


It does get a bit tedious, but I'm sort of used to typing ...

private {
   import ... ;
   import ... ;
 }

at the top of all my modules.

-- 
Derek
Melbourne, Australia
6/04/2005 2:47:00 PM

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Antonio Monteiro schrieb am Tue, 05 Apr 2005 03:24:23 -0400:
> Here is a problem I got using interfaces and classes
> (lets keep it simple)
>
> I reduced it to 6 modules and no external dependencies
>
> Walter, let me know if I can do something else.
>
> ################################
> here is the compiler command:
> dmd a.d b.d c.d dummy.d i.d util.d -I~/dmd/src/phobos
> ################################
> and the 6 source files:
> ################################
> module a;
> class A
> {
> }
> ################################
> module b;
> private import a;
> private import i;
>
> class B : A , I
> {
>          private import util;
>          private import dummy;
>
>          public A foo(Util util)
>          {
>          }
> }
<snip>

The only place wher ImportDeclarations are legal is the module scope. (http://digitalmars.com/d/module.html)

Added to DStress as http://dstress.kuehne.cn/nocompile/import_01.d http://dstress.kuehne.cn/nocompile/import_02.d http://dstress.kuehne.cn/nocompile/import_03.d http://dstress.kuehne.cn/nocompile/import_04.d http://dstress.kuehne.cn/nocompile/import_05.d

Thomas



-----BEGIN PGP SIGNATURE-----

iD8DBQFCU5pu3w+/yD4P9tIRAhVMAKCGEXKMNO55pZm8qP1kHBALU/jitgCfciZc
m6btEEkJhsEjXidQaSmUSc4=
=/PHZ
-----END PGP SIGNATURE-----

In article <ecici2-tg5.ln1@lnews.kuehne.cn>, Thomas Kuehne says...
>
>

>The only place wher ImportDeclarations are legal is the module scope.

Thank you, this is good to know.
I tried to confirm that 1.5 years ago but couldn't.
Now I can do things how D is suppose to support them...

Ant