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