compiler message:
"phobos/std/stdio.d: import std.stdio.object conflicts with Attributes.object at Attributes.d"

there is no Attributes.object.
changes I made to a other wise small program with about 20 modules and 25 classes:
- added global enum
- used the new enum as return type of a method overrided by several classes (class B:A , class C:B , class D:C ...).

Another day another old bug :)

I spend 2.5 hours with yesterday's bug, I can't do it again,
I need to see results from the time I put in.

aknowleadge that the bug report is usefull is a positive result.

:(

Ant

Antonio Monteiro wrote:

> compiler message:
> "phobos/std/stdio.d: import std.stdio.object conflicts with
> Attributes.object at Attributes.d"
> 
> there is no Attributes.object.
> changes I made to a other wise small program with about 20 modules and
> 25 classes:
> - added global enum
> - used the new enum as return type of a method overrided by several
> classes (class B:A , class C:B , class D:C ...).

Sample for reproduction?
Do you have by chance an object.d outside of Phobos?

Thomas

"Antonio Monteiro" <duitoolkit@yahoo.ca> wrote in message news:d30478$189q$1@digitaldaemon.com...
> compiler message:
> "phobos/std/stdio.d: import std.stdio.object conflicts with
> Attributes.object at Attributes.d"

I get this sort of message when I have a public import that hides the offending declaration. It is odd to have one about "object", though. I wonder if it is because of the implicit "import object" that appear at the front of all D modules?

In article <mqici2-hp5.ln1@lnews.kuehne.cn>, Thomas Kuehne says...
>

>Sample for reproduction?

I which...

>Do you have by chance an object.d outside of Phobos?

No.

Ant

In article <d30p9f$244e$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"Antonio Monteiro" <duitoolkit@yahoo.ca> wrote in message news:d30478$189q$1@digitaldaemon.com...
>> compiler message:
>> "phobos/std/stdio.d: import std.stdio.object conflicts with
>> Attributes.object at Attributes.d"
>
>I get this sort of message when I have a public import that hides the offending declaration. It is odd to have one about "object", though. I wonder if it is because of the implicit "import object" that appear at the front of all D modules?

ok, ok... lets see, lets help Walter to produce a better compiler message:
"hides declaration" what declaration? object?
maybe Attribute declares something with some other entry from object.d
(I don't have the code here)

I tried to add "private" to all my imports maybe I missed some.

(contrary to the
private {
    import ...;
}
I type it for all imports
and so make it easy to grep.)

Ant

"Ant" <Ant_member@pathlink.com> wrote in message news:d30s4j$2866$1@digitaldaemon.com...
> In article <d30p9f$244e$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>
>>"Antonio Monteiro" <duitoolkit@yahoo.ca> wrote in message news:d30478$189q$1@digitaldaemon.com...
>>> compiler message:
>>> "phobos/std/stdio.d: import std.stdio.object conflicts with
>>> Attributes.object at Attributes.d"
>>
>>I get this sort of message when I have a public import that hides the offending declaration. It is odd to have one about "object", though. I wonder if it is because of the implicit "import object" that appear at the front of all D modules?
>
> ok, ok... lets see, lets help Walter to produce a better compiler message:
> "hides declaration" what declaration? object?
> maybe Attribute declares something with some other entry from object.d
> (I don't have the code here)

Can you show us Attributes.d? Does it import std.stdio?

> I tried to add "private" to all my imports maybe I missed some.
>
> (contrary to the
> private {
>    import ...;
> }
> I type it for all imports
> and so make it easy to grep.)

me, too. I used to use private{ } but stopped exactly for tracking down these public/private conflicts.

In article <d30sp8$292q$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"Ant" <Ant_member@pathlink.com> wrote in message news:d30s4j$2866$1@digitaldaemon.com...
>> In article <d30p9f$244e$1@digitaldaemon.com>, Ben Hinkle says...
>>>
>>>
>>>"Antonio Monteiro" <duitoolkit@yahoo.ca> wrote in message news:d30478$189q$1@digitaldaemon.com...
>>>> compiler message:
>>>> "phobos/std/stdio.d: import std.stdio.object conflicts with
>>>> Attributes.object at Attributes.d"
>>>
>>>I get this sort of message when I have a public import that hides the offending declaration. It is odd to have one about "object", though. I wonder if it is because of the implicit "import object" that appear at the front of all D modules?
>>
>> ok, ok... lets see, lets help Walter to produce a better compiler message:
>> "hides declaration" what declaration? object?
>> maybe Attribute declares something with some other entry from object.d
>> (I don't have the code here)
>
>Can you show us Attributes.d?

later tonight I don't have it here.

> Does it import std.stdio?

probably: I'm changing all printf to writef.

that will change when I incorporate those functionalities into dool.
I think I better to that sooner ratther the later, if it's
another source of problems.

but that's not the change I made when the compiler started complaining!

Ant

Antonio Monteiro wrote:
> compiler message:
> "phobos/std/stdio.d: import std.stdio.object conflicts with Attributes.object at Attributes.d"
> 
> there is no Attributes.object.

Can this simply be the old missing imports?!

Yes, it is! :(

I tried moving all imports to the module level.
10 or 15 missing imports were found by the compiler!
added the missing ones and it compiles.

then I moved the imports back to the class body and "almost" compiles
(complain about a private var from the super class that is protected
AND the classes are defined on the same module).

If I am the only one using imports inside the class body should that be droped? Why do we have them on the first place?
I asked about this over a year ago.

Ant