Re: Why does std.string use public imports?
On 2011-06-30 17:12, Jonathan M Davis wrote:
On 2011-06-30 16:14, Andrej Mitrovic wrote:
I'm referring to these two in std.string:
public import std.algorithm : startsWith, endsWith, cmp, count;
public import std.array : join, split;
Because whenever I try to use .count in my code:
import std.stdio;
import std.string;
import std.utf;
void main()
{
writeln(foo.count);
}
std.utf.count conflicts with std.string's publicly imported
std.algorithm.count
Can we avoid public imports in modules? The rise of conflicts in
Phobos is getting slightly annoying.
I believe that they're there because the functions in question used to be
in std.string but were generalized and moved to other modules. So, rather
than immediately break code, they were publicly imported in std.string.
They're scheduled for deprecation and will be removed once the deprecation
process has completed. However, they shouldn't be causing conflicts. It's
probably due to a bug related to explicit imports being seen as new
functions in the module that they're imported into (I forget the bug
number). Maybe using static imports with aliases would fix the problem.
Actually, now that I look at it more closely, the problem that you're seeing
is fully expected and desired. It's complaining that std.string has a count
function and that std.utf has a count function and that it doesn't know which
to use. That's exactly what's supposed to happen when two modules have
functions which conflict. std.string has had a count function for a long time.
So, this is the behavior that you would have seen for a long time.
std.string's count has been generalized and moved to std.algorithm, so you're
going to get the same conflict between std.algorithm.count and std.utf.count -
which is expected. The public import is part of the deprecation and will go
away eventually. At that point, std.string and std.utf will no longer conflict
for count, because std.string won't have a count function anymore. But there's
no bug here. What you're seeing here is exactly what std.string and std.utf
have been doing for some time. It's a natural side effect of using the same
function name in multiple modules. Using the full module path for the function
fixes the problem (though it doesn't work with the member function call syntax
in that case). It's how the module system works and fully expected.
- Jonathan M Davis
Re: Why does std.string use public imports?
On 01.07.2011 22:06, Jonathan M Davis wrote:
On 2011-06-30 17:12, Jonathan M Davis wrote:
On 2011-06-30 16:14, Andrej Mitrovic wrote:
I'm referring to these two in std.string:
public import std.algorithm : startsWith, endsWith, cmp, count;
public import std.array : join, split;
Because whenever I try to use .count in my code:
import std.stdio;
import std.string;
import std.utf;
void main()
{
writeln(foo.count);
}
std.utf.count conflicts with std.string's publicly imported
std.algorithm.count
Can we avoid public imports in modules? The rise of conflicts in
Phobos is getting slightly annoying.
I believe that they're there because the functions in question used to be
in std.string but were generalized and moved to other modules. So, rather
than immediately break code, they were publicly imported in std.string.
They're scheduled for deprecation and will be removed once the deprecation
process has completed. However, they shouldn't be causing conflicts. It's
probably due to a bug related to explicit imports being seen as new
functions in the module that they're imported into (I forget the bug
number). Maybe using static imports with aliases would fix the problem.
Actually, now that I look at it more closely, the problem that you're seeing
is fully expected and desired. It's complaining that std.string has a count
function and that std.utf has a count function and that it doesn't know which
to use. That's exactly what's supposed to happen when two modules have
functions which conflict. std.string has had a count function for a long time.
So, this is the behavior that you would have seen for a long time.
std.string's count has been generalized and moved to std.algorithm, so you're
going to get the same conflict between std.algorithm.count and std.utf.count -
which is expected. The public import is part of the deprecation and will go
away eventually. At that point, std.string and std.utf will no longer conflict
for count, because std.string won't have a count function anymore. But there's
no bug here. What you're seeing here is exactly what std.string and std.utf
have been doing for some time. It's a natural side effect of using the same
function name in multiple modules. Using the full module path for the function
fixes the problem (though it doesn't work with the member function call syntax
in that case). It's how the module system works and fully expected.
- Jonathan M Davis
Isn't it expected that std.string contains a count method?
import std.stdio;
import std.string;
void main() {
auto s = à;
writeln(s.length); // 2 - often you want the actual number of
characters, not code points
writeln(s.count()); // 1 - should a user need to import count from
algorithm/utf to get this?
}
Re: Why does std.string use public imports?
On 7/1/11, Jonathan M Davis jmdavisp...@gmx.com wrote:
On 2011-06-30 17:12, Jonathan M Davis wrote:
On 2011-06-30 16:14, Andrej Mitrovic wrote:
I'm referring to these two in std.string:
public import std.algorithm : startsWith, endsWith, cmp, count;
public import std.array : join, split;
Because whenever I try to use .count in my code:
import std.stdio;
import std.string;
import std.utf;
void main()
{
writeln(foo.count);
}
std.utf.count conflicts with std.string's publicly imported
std.algorithm.count
Can we avoid public imports in modules? The rise of conflicts in
Phobos is getting slightly annoying.
I believe that they're there because the functions in question used to be
in std.string but were generalized and moved to other modules. So, rather
than immediately break code, they were publicly imported in std.string.
They're scheduled for deprecation and will be removed once the deprecation
process has completed. However, they shouldn't be causing conflicts. It's
probably due to a bug related to explicit imports being seen as new
functions in the module that they're imported into (I forget the bug
number). Maybe using static imports with aliases would fix the problem.
Actually, now that I look at it more closely, the problem that you're seeing
is fully expected and desired. It's complaining that std.string has a count
function and that std.utf has a count function and that it doesn't know
which
to use. That's exactly what's supposed to happen when two modules have
functions which conflict. std.string has had a count function for a long
time.
So, this is the behavior that you would have seen for a long time.
std.string's count has been generalized and moved to std.algorithm, so
you're
going to get the same conflict between std.algorithm.count and std.utf.count
-
which is expected. The public import is part of the deprecation and will go
away eventually. At that point, std.string and std.utf will no longer
conflict
for count, because std.string won't have a count function anymore. But
there's
no bug here. What you're seeing here is exactly what std.string and std.utf
have been doing for some time. It's a natural side effect of using the same
function name in multiple modules. Using the full module path for the
function
fixes the problem (though it doesn't work with the member function call
syntax
in that case). It's how the module system works and fully expected.
- Jonathan M Davis
When did I ever say it was a bug? I said it's annoying that there's
conflicts due to public imports. If it's going away, good. I know
algorithm has count, but I never imported that module, std.string
imported it publicly so I got conflicts even though I was trying to
avoid them.
Re: Why does std.string use public imports?
On 2011-07-01 14:58, Andrej Mitrovic wrote:
On 7/1/11, Jonathan M Davis jmdavisp...@gmx.com wrote:
On 2011-06-30 17:12, Jonathan M Davis wrote:
On 2011-06-30 16:14, Andrej Mitrovic wrote:
I'm referring to these two in std.string:
public import std.algorithm : startsWith, endsWith, cmp, count;
public import std.array : join, split;
Because whenever I try to use .count in my code:
import std.stdio;
import std.string;
import std.utf;
void main()
{
writeln(foo.count);
}
std.utf.count conflicts with std.string's publicly imported
std.algorithm.count
Can we avoid public imports in modules? The rise of conflicts in
Phobos is getting slightly annoying.
I believe that they're there because the functions in question used to
be in std.string but were generalized and moved to other modules. So,
rather than immediately break code, they were publicly imported in
std.string. They're scheduled for deprecation and will be removed once
the deprecation process has completed. However, they shouldn't be
causing conflicts. It's probably due to a bug related to explicit
imports being seen as new functions in the module that they're imported
into (I forget the bug number). Maybe using static imports with aliases
would fix the problem.
Actually, now that I look at it more closely, the problem that you're
seeing is fully expected and desired. It's complaining that std.string
has a count function and that std.utf has a count function and that it
doesn't know which
to use. That's exactly what's supposed to happen when two modules have
functions which conflict. std.string has had a count function for a long
time.
So, this is the behavior that you would have seen for a long time.
std.string's count has been generalized and moved to std.algorithm, so
you're
going to get the same conflict between std.algorithm.count and
std.utf.count -
which is expected. The public import is part of the deprecation and will
go away eventually. At that point, std.string and std.utf will no longer
conflict
for count, because std.string won't have a count function anymore. But
there's
no bug here. What you're seeing here is exactly what std.string and
std.utf have been doing for some time. It's a natural side effect of
using the same function name in multiple modules. Using the full module
path for the function
fixes the problem (though it doesn't work with the member function call
syntax
in that case). It's how the module system works and fully expected.
- Jonathan M Davis
When did I ever say it was a bug? I said it's annoying that there's
conflicts due to public imports. If it's going away, good. I know
algorithm has count, but I never imported that module, std.string
imported it publicly so I got conflicts even though I was trying to
avoid them.
Well, for some functions, conflicts are going to be pretty much inevitable.
And the number is only likely to go up as Phobos' size increases. Smart
function naming reduces it, but sometimes the best name is the same name as
one which already exists, and conflicts are going to happen. They won't
normally be public imports like that, but they're going to happen.
- Jonathan M Davis
Why does std.string use public imports?
I'm referring to these two in std.string:
public import std.algorithm : startsWith, endsWith, cmp, count;
public import std.array : join, split;
Because whenever I try to use .count in my code:
import std.stdio;
import std.string;
import std.utf;
void main()
{
writeln(foo.count);
}
std.utf.count conflicts with std.string's publicly imported std.algorithm.count
Can we avoid public imports in modules? The rise of conflicts in
Phobos is getting slightly annoying.
Re: Why does std.string use public imports?
On 01.07.2011 01:14, Andrej Mitrovic wrote:
I'm referring to these two in std.string:
public import std.algorithm : startsWith, endsWith, cmp, count;
public import std.array : join, split;
Because whenever I try to use .count in my code:
import std.stdio;
import std.string;
import std.utf;
void main()
{
writeln(foo.count);
}
std.utf.count conflicts with std.string's publicly imported std.algorithm.count
Can we avoid public imports in modules? The rise of conflicts in
Phobos is getting slightly annoying.
I cannot comment on the count issue, but if I was to import only
std.string and I was missing basic functionality like the ones imported
here, it would have annoyed me :) So it's good if it makes sense I think.
Re: Why does std.string use public imports?
That makes sense, I understand. But I hate these conflicts. I've got `alias std.bla.foo foo` scattered in most of my code due to constant conflicts. :/
Re: Why does std.string use public imports?
On 2011-06-30 16:14, Andrej Mitrovic wrote:
I'm referring to these two in std.string:
public import std.algorithm : startsWith, endsWith, cmp, count;
public import std.array : join, split;
Because whenever I try to use .count in my code:
import std.stdio;
import std.string;
import std.utf;
void main()
{
writeln(foo.count);
}
std.utf.count conflicts with std.string's publicly imported
std.algorithm.count
Can we avoid public imports in modules? The rise of conflicts in
Phobos is getting slightly annoying.
I believe that they're there because the functions in question used to be in
std.string but were generalized and moved to other modules. So, rather than
immediately break code, they were publicly imported in std.string. They're
scheduled for deprecation and will be removed once the deprecation process has
completed. However, they shouldn't be causing conflicts. It's probably due to
a bug related to explicit imports being seen as new functions in the module
that they're imported into (I forget the bug number). Maybe using static
imports with aliases would fix the problem.
- Jonathan M Davis
Re: Why does std.string use public imports?
Andrej Mitrovic Wrote: I'm referring to these two in std.string: public import std.algorithm : startsWith, endsWith, cmp, count; public import std.array : join, split; I'm not sure why they are public, but selective/named imports have been publicly imported for some time. Bugzilla 3?? I think.
