On Wednesday, 16 August 2017 at 17:14:49 UTC, jmh530 wrote:
On Wednesday, 16 August 2017 at 14:42:51 UTC, Mike Wey wrote:Wouldn't that just move the problem?You then get an package that imports gtk.Window and a other package that imports gdk.Window, and if you want to use both you still need to add a renamed import or a static import in your own file.I don't know anything about gtkd, but I think he means something like below..\gtkd\package.d module gtkd; public import gtk; public import gdk; ...etc .\gtkd\gtk\package.d module gtk; public import gtk.Window; ...etc .\gtkd\gdk\package.d module gdk; public import gdk.Window; ...etc So you should then be able to do something like import gtkd : functionThatDoesntOverlap; import gtk = gtkd.gtk : functionThatDoesOverlap; import gdk = gtkd.gdk : functionThatDoesOverlap; A longer-term solution is for something like import gtkd;to only pull in the functions/structs/classes/etc that are actually used.
Not really, I'm not doing selective imports.I want to be able to use an import symbol that contains a whole crapload of imports. Which, the only way now is to create a separate file and public import all those imports one wants, then use that file and name it.
test.d import _gtk = crapload; import _gdk = crapload2; crapload.d public import gtk.TreeView; public import gtk.Window; .... crapload2.d public import gdk.Window .... But this requires creating files for every one group one wants.It would be much nicer and easier, and it is easy if D added the language feature, to do
import _gtk = {gtk.TreeView, gtk.Window, ... }
import _gdk = {gdk.Window, ... }
The semantics are the same, it is just a rewrite rule
basically... but all it really solves is not requiring extra
files, which means keeping track of more junk.
It's not necessarily all that useful if one uses such imports all the time since it would bloat the files, But we could then add some wildcards:
import _gtk = gtk.*; import _gdk = gdk.*; which would be functionally the same but far less verbose.But as it stands now, there is only one way to do that and that way is the most verbose and hardest to maintain... that really isn't acceptable when it is such an easy problem to fix and doesn't have any downside in implementing it.
