the point of selective importing
Jari-Matti Mäkelä
jmjmak at utu.fi.invalid
Tue Jul 11 17:45:30 PDT 2006
kris wrote:
> Jari-Matti Mäkelä wrote:
>> Derek Parnell wrote:
>>
>>> On Tue, 11 Jul 2006 23:20:39 +0300, Jari-Matti Mäkelä wrote:
>>>
>>>
>>>> In my
>>>> experience if your having more than 1-2 conflicting members, you're
>>>> doing something wrong.
>>>
>>> That might be true if all the modules you use are under your direct
>>> control. However, the times I've had name clashes have been due to using
>>> libraries written by other people who, independently, decided to use the
>>> same name. Thus in my code, I am forced to disambiguate them.
>>> Consider the simple situation in Phobos
>>>
>>> std.string.find
>>> std.regexp.find
>>> internal.gc.gcx.find
>>>
>>> then add the various other 'find' members in external libraries.
>>
>>
>> Ok, have to admit that's true. But do you really use them all in the
>> same module? If there's only a small amount of conflicting names, the
>> import syntax does not have to be so incredibly complex.
>
>
> It can and will happen. The larger the project, the better the chance
> for conflicts. There's probably some logarithmic-style graph describing
> the relationship between the number of modules and the resulting number
> of potential conflicts. The issue does not really arise within small or
> personal projects to the same extent. Primarily because you personally
> have full control over the entire namespace.
Of course. But I only wanted to say that this does not justify the use
of a complex import statement syntax (the one Rioshin proposed). I
though the whole issue now was that Rioshin's syntax is better because
it requires less typing, when multiple members of the same module conflict:
static import
in very.long.module.name alias mn
member1 alias m1,
member2 alias m2,
member3 alias m3;
versus
import very.long.module.name as mn,
very.long.module.name.member1 as m1,
very.long.module.name.member2 as m2,
very.long.module.name.member3 as m3;
IMHO the latter version is much better. Simpler compiler implementation,
less syntax rules, less reserved symbols - one can easily replace 'as'
with : as you said earlier. And the best of all is that this is fully
backwards compatible with the current syntax.
The thing I was saying was that when there's a common guideline to
create as little public members to the module as possible, it's much
easier to import the whole module either to the global namespace or to a
custom namespace
import very.long.module.name as mn; // or
import very.long.module.name;
and not import individual members at all (if possible). That way the
syntax I proposed would not cause so much typing. AFAICS it's pretty
much the same to use
import module as a, module2 as b;
a.foo();
b.foo();
as
import module.foo as afoo, module2.foo as bfoo;
afoo();
bfoo();
> The syntax itself does not need to be complex at all.
Right. I only meant that the syntax does not have to be a monster like this
[<protection>] [static] import {[in]} <FQN Module> [alias <Module Alias>]
{[<<Member> [alias <Member Alias>]>[, ...]]};
(I think Rioshin even forgot to include 'as' keyword to the syntax above
- that would probably make it a pain to implement if it isn't already)
My own proposal (actually it's partly stolen from many other proposals)
is to have only
[private] import <fqn module / module member> as <local module namespace
/ imported member name>, ...;
The Derek's problem could be then solved by doing:
import std.string.find as find1,
std.regexp.find as find2,
internal.gc.gcx.find as find3;
find1(...);
find2(...);
find3(...);
or
import std.string as s, std.regexp as r, internal.gc.gcx as g;
s.find(...);
r.find(...);
g.find(...);
> No static, no alias. Looks very much like the existing import, and is
> almost as effortless to use. Perhaps you might like to read the "Import
> RFC" posted? It explains the issues in a little more depth.
kris, I read it already. It seems that I have overlooked the name
conflict issue. I'm sorry, I'm not a library guru yet. I'll try to shut
up when I don't get it, but here I though a simple solution would help.
I agree with you fully, but don't get it why Derek's or Rioshin's
proposal is "good" in any way.
--
Jari-Matti
More information about the Digitalmars-d
mailing list