In article <ops5425bcg23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>I believe Walter discourages the use of import inside a class and I believe your use of them is the reason for the problem.

I need to make a joke and a note:

so we have a ternary logic:
- import in module: true
- import in function: false
- import in class: maybe

so we need a new type: the ternarybit or TBit or TimBit for Canadians.
(sorry regional joke)

and

I'm getting better response when I do "angry" posts then with polite posts. I'll keep it up ;)

Ant

I had the same problem. Removing std.something from one of the modules where it wasn't used at all fixed the problem...

Ant wrote:
> Walter, we still have:
> 
> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
> 
> 
> these are both private import std.string;
> 
> the interesting thing is that I had a
> private import std.c.stdio;
> in one module that would supply std.string to a bunch of other modules
> 
> well, I know you cannot do anything about this
> and I know I cannot reduce this problem... but it's better than 2 year ago! :)
> 
> Ant

In article <duphvm$hnm$1@digitaldaemon.com>, bobef says...
>
>I had the same problem. Removing std.something from one of the modules where it wasn't used at all fixed the problem...
>
>Ant wrote:
>> the interesting thing is that I had a
>> private import std.c.stdio;
>> in one module that would supply std.string to a bunch of other modules
>> 

I think this is much more important then Walter does.
This will prevent D to be used in any sizeable project that involves
more then one coder.
Is somebody else adds the wrong import on some module I never saw my
code will break :(

Ant

On Fri, 10 Mar 2006 00:28:50 +1100, Ant <Ant_member@pathlink.com> wrote:

> In article <ops5425bcg23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>
>> I believe Walter discourages the use of import inside a class and I
>> believe your use of them is the reason for the problem.
>
> I need to make a joke and a note:
>
> so we have a ternary logic:
> - import in module: true
> - import in function: false
> - import in class: maybe

Why would one think of importing stuff into a class? I don't get it. Are you trying to make the imported stuff 'local' to the class members and nothing else?

-- 
Derek Parnell
Melbourne, Australia

In article <dupjbv$jti$1@digitaldaemon.com>, Ant says...
>
>In article <duphvm$hnm$1@digitaldaemon.com>, bobef says...
>>
>>I had the same problem. Removing std.something from one of the modules where it wasn't used at all fixed the problem...
>>
>>Ant wrote:
>>> the interesting thing is that I had a
>>> private import std.c.stdio;
>>> in one module that would supply std.string to a bunch of other modules
>>> 
>
>I think this is much more important then Walter does.
>This will prevent D to be used in any sizeable project that involves
>more then one coder.
>Is somebody else adds the wrong import on some module I never saw my
>code will break :(
>
>Ant

I think it's an important issue because I know I've wasted a lot of time dealing with similar import errors, but I don't think that Walter actually needs to change the "rules of importing". More descriptive (i.e. helpful) error messages might be all that is needed.

I've posted some suggestions about this in the past, but I don't think Walter has had a chance to work on it yet (assuming he even agrees that situation needs to improve).

jcc7

Derek Parnell wrote:

> On Fri, 10 Mar 2006 00:28:50 +1100, Ant <Ant_member@pathlink.com> wrote:
> 
>> In article <ops5425bcg23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>>
>>> I believe Walter discourages the use of import inside a class and I believe your use of them is the reason for the problem.
>>
>> I need to make a joke and a note:
>>
>> so we have a ternary logic:
>> - import in module: true
>> - import in function: false
>> - import in class: maybe
> 
> Why would one think of importing stuff into a class? I don't get it. Are you trying to make the imported stuff 'local' to the class members and nothing else?
> 

Because when Ant first wrote DUI, class local imports were a workaround to much bigger import problems than those we meet today.

bobef wrote:
> I had the same problem. Removing std.something from one of the modules where it wasn't used at all fixed the problem...

Ok, this is currently a working workaround - but it isn't a valid solution. Try to create a huge framework with 100+ modules and then draw a module dependency graph on a paper. You'll see that it becomes almost impossible to find out, which module you "should" import to avoid these conflicts.

This might not be a problem if you write your code (one module at a time) without any previously generated UML graphs, but in a corporate environment this behavior forces you to test your code every once in a while since it's completely possible that a code generator is used to generate the module&class signatures. Currently D modules don't scale very well here. IMHO that's not a practical solution (Walter - hint, hint <g>).


> 
> Ant wrote:
>> Walter, we still have:
>>
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>>
>>
>> these are both private import std.string;
>>
>> the interesting thing is that I had a
>> private import std.c.stdio;
>> in one module that would supply std.string to a bunch of other modules
>>
>> well, I know you cannot do anything about this
>> and I know I cannot reduce this problem... but it's better than 2 year
>> ago! :)
>>
>> Ant

In article <dupl7t$mqk$1@digitaldaemon.com>, Lars Ivar Igesund says...
>
>Derek Parnell wrote:
>
>> On Fri, 10 Mar 2006 00:28:50 +1100, Ant <Ant_member@pathlink.com> wrote:
>> 
>>> In article <ops5425bcg23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>>>
>>>> I believe Walter discourages the use of import inside a class and I believe your use of them is the reason for the problem.
>>>
>>> I need to make a joke and a note:
>>>
>>> so we have a ternary logic:
>>> - import in module: true
>>> - import in function: false
>>> - import in class: maybe
>> 
>> Why would one think of importing stuff into a class? I don't get it. Are you trying to make the imported stuff 'local' to the class members and nothing else?
>> 
>
>Because when Ant first wrote DUI, class local imports were a workaround to much bigger import problems than those we meet today.

yes, and more,
I'm going to use the import symbols inside the class body,
what makes no sence is to have the import at the module level - see there
is always another way to look at things.

and more,
If I have multiple classes in the same module maybe it makes sence to
import the specific modules to the right class.

Anyway, this needs to be reviewd.

And import in classes should either be corrected (please) or made illegal(no).

Ant

On Fri, 10 Mar 2006 04:40:15 +1100, Ant <Ant_member@pathlink.com> wrote:

> In article <dupl7t$mqk$1@digitaldaemon.com>, Lars Ivar Igesund says...
>>
>> Derek Parnell wrote:
>>
>>> On Fri, 10 Mar 2006 00:28:50 +1100, Ant <Ant_member@pathlink.com> wrote:
>>>
>>>> In article <ops5425bcg23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>>>>
>>>>> I believe Walter discourages the use of import inside a class and I
>>>>> believe your use of them is the reason for the problem.
>>>>
>>>> I need to make a joke and a note:
>>>>
>>>> so we have a ternary logic:
>>>> - import in module: true
>>>> - import in function: false
>>>> - import in class: maybe
>>>
>>> Why would one think of importing stuff into a class? I don't get it. Are
>>> you trying to make the imported stuff 'local' to the class members and
>>> nothing else?
>>>
>>
>> Because when Ant first wrote DUI, class local imports were a workaround to
>> much bigger import problems than those we meet today.
>
> yes, and more,
> I'm going to use the import symbols inside the class body,
> what makes no sence is to have the import at the module level - see there
> is always another way to look at things.
>
> and more,
> If I have multiple classes in the same module maybe it makes sence to
> import the specific modules to the right class.

But this is the part I don't get. In my opinion, it does make sense to import at the module level, because in D everything in the same module is accessible. Multiple classes in the same module *means* that they are friends and thus can access each other's internals. So importing at the class level can not restrict access between classes residing in the same module. If you really must have restricted access you must also split the classes into different modules.

> Anyway, this needs to be reviewd.
>
> And import in classes should either be corrected (please) or made illegal(no).

Yes, this does need reviewing and clarificaton. I imagine that the simplest 'correction' would be to that if an import is found inside an aggregate (class or struct) then just assume it to be at the module level.

To improve the access granularity, we would need a new scoping keyword (e.g. 'local') in order to sign those members that are only accessible from within the same class/struct.

-- 
Derek Parnell
Melbourne, Australia

Ant wrote:
> Walter, we still have:
> 
> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
> 
> 
> these are both private import std.string;
> 
> the interesting thing is that I had a
> private import std.c.stdio;
> in one module that would supply std.string to a bunch of other modules
> 
> well, I know you cannot do anything about this
> and I know I cannot reduce this problem... but it's better than 2 year ago! :)
> 
> Ant

please forgive me I was mistaken.
this is as bad as 2 years ago.

Ant