www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3505] New: [module] static imports should be binded to the leaf module, not the fully qualified name

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3505

           Summary: [module] static imports should be binded to the leaf
                    module, not the fully qualified name
           Product: D
           Version: future
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: llucax gmail.com



PST ---
Now static imports uses full qualified module names:

  static import foo.bar.baz;
  foo.bar.baz.f();

It would be much nicer to avoid a lot of typing to make them bind to the leaf
module:

  static import foo.bar.baz;
  baz.f();

This removes a lot of clutter from static import and make renamed import almost
useless. I do this manually most of the time:

  import baz = foo.bar.baz;
  baz.f();

Which is clumsier.

This feature would be great specially if all imports are static by default (see
bug 3503).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 13 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3505


Bill Baxter <wbaxter gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wbaxter gmail.com



Maybe something like this could be allowed to mean "import renamed to the
leaf":

    import (foo.bar.)MyModule;

Sometimes I do want the actually fully qualified name, like for a module like
std.string.  Having "string" mucks with the type "string".  Or maybe parens
around the part to keep:

    import foo.bar.(MyModule);

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 14 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3505




PST ---

 Maybe something like this could be allowed to mean "import renamed to the
 leaf":
 
     import (foo.bar.)MyModule;
 
 Sometimes I do want the actually fully qualified name, like for a module like
 std.string.  Having "string" mucks with the type "string".  Or maybe parens
 around the part to keep:
 
     import foo.bar.(MyModule);
I think it's very unfortunate to have a module with the same name of an almost built-in type. Maybe the module can be renamed to std.str; or we can live with: import str = std.string; Another possibility is, if bug 3503 gets implemented, is to leave static import untouched. I think that's even a good idea for backwards compatibility. static import std.string; import std.algorithm; std.string.foo(); algorithm.sort(); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 14 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3505


dawg dawgfoto.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dawg dawgfoto.de
         Resolution|                            |WONTFIX



It seems that renamed imports are sufficient for this given how much code it
would break.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 13 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3505




2012-02-13 11:10:27 PST ---

 It seems that renamed imports are sufficient for this given how much code it
 would break.
You might want to close bug 3503 and bug 3504 then too, because they were part of the same proposal to rethink the module system. This also was before D2 was considered frozen and there was some place to make breaking changes, now I don't think it will happen until a very major update, which doesn't seems to be very close either. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 13 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3505




I have to say though that I fully agree with your proposals.
Only it's a controversial thing and has way too much impact to
be still considered.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 13 2012