www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Named multi-imports

reply Johnson <Johnson Johnson.com> writes:
Why can't we name multiple imports?

import x = a, b, c;

only a is part of x, b and c are not named!

this can cause some major problems(or the lack of a correctly 
solution).

For example,

gdk and gtk both have window. Both imports are needed and both 
define many public imports that create a huge spaghetti of mixed 
imports. In my code, even without gdk.Window imported, I am 
getting variables that are of that time, even though I import 
gtk.Window. I declare the variables as Window because it is 
automatically generated code and I do not know the actual 
import(well, unless I manually create a map from all the D 
imports to the glade types).

But I use gdk in just a few areas.

The only solution is to create a separate pulbic imports file 
that holds all the imports, but this creates extra files.

Why not something like

import x = {a,b,c};

?


It's a natural extension, makes sense, and should be easy to work 
out. Avoids having extra files for no other reason that to do the 
above and should easily solve the conflicts. What's nice about it 
is that we can even do

import x =
{
  a,
  b,
  c
};

which is like

public
{

}

 {att}
{

}


etc...




See what I mean:



public import gtk.AboutDialog;
public import gtk.AccelGroup;
public import gtk.AccelLabel;
public import gtk.AccelMap;
public import gtk.Accessible;
public import gtk.Action;
public import gtk.ActionableIF;
public import gtk.ActionableT;
public import gtk.ActionBar;
public import gtk.ActionGroup;
public import gtk.ActivatableIF;
public import gtk.ActivatableT;
public import gtk.Adjustment;
public import gtk.Alignment;
public import gtk.AppChooserButton;
public import gtk.AppChooserDialog;
public import gtk.AppChooserIF;
public import gtk.AppChooserT;
public import gtk.AppChooserWidget;
public import gtk.Application;
public import gtk.ApplicationWindow;
public import gtk.Arrow;
public import gtk.ArrowAccessible;
public import gtk.AspectFrame;
public import gtk.Assistant;
public import gtk.Bin;
public import gtk.BindingEntry;
public import gtk.BindingSet;
public import gtk.BooleanCellAccessible;
public import gtk.Border;
public import gtk.Box;
public import gtk.BuildableIF;
public import gtk.BuildableT;
public import gtk.Builder;
public import gtk.Button;
public import gtk.ButtonAccessible;
public import gtk.ButtonBox;
public import gtk.Calendar;
public import gtk.CellAccessible;
public import gtk.CellAccessibleParentIF;
public import gtk.CellAccessibleParentT;
public import gtk.CellArea;
public import gtk.CellAreaBox;
public import gtk.CellAreaClass;
public import gtk.CellAreaContext;
public import gtk.CellEditable;
public import gtk.CellEditableIF;
public import gtk.CellEditableT;
public import gtk.CellLayoutIF;
public import gtk.CellLayoutT;
public import gtk.CellRenderer;
public import gtk.CellRendererAccel;
public import gtk.CellRendererClass;
public import gtk.CellRendererCombo;
public import gtk.CellRendererPixbuf;
public import gtk.CellRendererProgress;
public import gtk.CellRendererSpin;
public import gtk.CellRendererSpinner;
public import gtk.CellRendererText;
public import gtk.CellRendererToggle;
public import gtk.CellView;
public import gtk.CheckButton;
public import gtk.CheckMenuItem;
public import gtk.CheckMenuItemAccessible;
public import gtk.Clipboard;
public import gtk.ColorButton;
public import gtk.ColorChooserDialog;
public import gtk.ColorChooserIF;
public import gtk.ColorChooserT;
public import gtk.ColorChooserWidget;
public import gtk.ColorSelection;
public import gtk.ColorSelectionDialog;
public import gtk.ComboBox;
public import gtk.ComboBoxAccessible;
public import gtk.ComboBoxText;
public import gtk.Container;
public import gtk.ContainerAccessible;
public import gtk.ContainerCellAccessible;
public import gtk.ContainerClass;
public import gtk.CssProvider;
public import gtk.CssSection;
public import gtk.Dialog;
public import gtk.DragAndDrop;
public import gtk.DrawingArea;
public import gtk.EditableIF;
public import gtk.EditableT;
public import gtk.Entry;
public import gtk.EntryAccessible;
public import gtk.EntryBuffer;
public import gtk.EntryCompletion;
public import gtk.EventBox;
public import gtk.EventController;
public import gtk.Expander;
public import gtk.ExpanderAccessible;
public import gtk.FileChooserButton;
public import gtk.FileChooserDialog;
public import gtk.FileChooserIF;
public import gtk.FileChooserNative;
public import gtk.FileChooserT;
public import gtk.FileChooserWidget;
public import gtk.FileFilter;
public import gtk.Fixed;
public import gtk.FlowBox;
public import gtk.FlowBoxAccessible;
public import gtk.FlowBoxChild;
public import gtk.FlowBoxChildAccessible;
public import gtk.FontButton;
public import gtk.FontChooserDialog;
public import gtk.FontChooserIF;
public import gtk.FontChooserT;
public import gtk.FontChooserWidget;
public import gtk.FontSelection;
public import gtk.FontSelectionDialog;
public import gtk.Frame;
public import gtk.FrameAccessible;
public import gtk.Gesture;
public import gtk.GestureDrag;
public import gtk.GestureLongPress;
public import gtk.GestureMultiPress;
public import gtk.GesturePan;
public import gtk.GestureRotate;
public import gtk.GestureSingle;
public import gtk.GestureSwipe;
public import gtk.GestureZoom;
public import gtk.GLArea;
public import gtk.Gradient;
public import gtk.Grid;
public import gtk.HandleBox;
public import gtk.HBox;
public import gtk.HButtonBox;
public import gtk.HeaderBar;
public import gtk.HPaned;
public import gtk.HScale;
public import gtk.HScrollbar;
public import gtk.HSeparator;
public import gtk.HSV;
public import gtk.IconFactory;
public import gtk.IconInfo;
public import gtk.IconSet;
public import gtk.IconSize;
public import gtk.IconSource;
public import gtk.IconTheme;
public import gtk.IconView;
public import gtk.IconViewAccessible;
public import gtk.Image;
public import gtk.ImageAccessible;
public import gtk.ImageCellAccessible;
public import gtk.ImageMenuItem;
public import gtk.IMContext;
public import gtk.IMContextSimple;
public import gtk.IMMulticontext;
public import gtk.InfoBar;
public import gtk.Invisible;
public import gtk.Label;
public import gtk.LabelAccessible;
public import gtk.Layout;
public import gtk.LevelBar;
public import gtk.LevelBarAccessible;
public import gtk.LinkButton;
public import gtk.LinkButtonAccessible;
public import gtk.ListBox;
public import gtk.ListBoxAccessible;
public import gtk.ListBoxRow;
public import gtk.ListBoxRowAccessible;
public import gtk.ListStore;
public import gtk.LockButton;
public import gtk.LockButtonAccessible;
public import gtk.Main;
public import gtk.MainWindow;
public import gtk.Menu;
public import gtk.MenuAccessible;
public import gtk.MenuBar;
public import gtk.MenuButton;
public import gtk.MenuButtonAccessible;
public import gtk.MenuItem;
public import gtk.MenuItemAccessible;
public import gtk.MenuShell;
public import gtk.MenuShellAccessible;
public import gtk.MenuToolButton;
public import gtk.MessageDialog;
public import gtk.Misc;
public import gtk.ModelButton;
public import gtk.MountOperation;
public import gtk.NativeDialog;
public import gtk.Notebook;
public import gtk.NotebookAccessible;
public import gtk.NotebookPageAccessible;
public import gtk.NumerableIcon;
public import gtk.OffscreenWindow;
public import gtk.OrientableIF;
public import gtk.OrientableT;
public import gtk.Overlay;
public import gtk.PadController;
public import gtk.PageSetup;
public import gtk.Paned;
public import gtk.PanedAccessible;
public import gtk.PaperSize;
public import gtk.PlacesSidebar;
public import gtk.Plug;
public import gtk.Popover;
public import gtk.PopoverAccessible;
public import gtk.PopoverMenu;
public import gtk.PopupBox;
public import gtk.PrintContext;
public import gtk.PrintOperation;
public import gtk.PrintOperationPreview;
public import gtk.PrintOperationPreviewIF;
public import gtk.PrintOperationPreviewT;
public import gtk.PrintSettings;
public import gtk.ProgressBar;
public import gtk.ProgressBarAccessible;
public import gtk.RadioAction;
public import gtk.RadioButton;
public import gtk.RadioButtonAccessible;
public import gtk.RadioMenuItem;
public import gtk.RadioMenuItemAccessible;
public import gtk.RadioToolButton;
public import gtk.Range;
public import gtk.RangeAccessible;
public import gtk.RcProperty;
public import gtk.RcStyle;
public import gtk.RecentAction;
public import gtk.RecentChooserDialog;
public import gtk.RecentChooserIF;
public import gtk.RecentChooserMenu;
public import gtk.RecentChooserT;
public import gtk.RecentChooserWidget;
public import gtk.RecentFilter;
public import gtk.RecentInfo;
public import gtk.RecentManager;
public import gtk.RendererCellAccessible;
public import gtk.Requisition;
public import gtk.Revealer;
public import gtk.Scale;
public import gtk.ScaleAccessible;
public import gtk.ScaleButton;
public import gtk.ScaleButtonAccessible;
public import gtk.ScrollableIF;
public import gtk.ScrollableT;
public import gtk.Scrollbar;
public import gtk.ScrolledWindow;
public import gtk.ScrolledWindowAccessible;
public import gtk.SearchBar;
public import gtk.SearchEntry;
public import gtk.SelectionData;
public import gtk.Separator;
public import gtk.SeparatorMenuItem;
public import gtk.SeparatorToolItem;
public import gtk.Settings;
public import gtk.ShortcutLabel;
public import gtk.ShortcutsGroup;
public import gtk.ShortcutsSection;
public import gtk.ShortcutsShortcut;
public import gtk.ShortcutsWindow;
public import gtk.SizeGroup;
public import gtk.Socket;
public import gtk.SpinButton;
public import gtk.SpinButtonAccessible;
public import gtk.Spinner;
public import gtk.SpinnerAccessible;
public import gtk.Stack;
public import gtk.StackAccessible;
public import gtk.StackSidebar;
public import gtk.StackSwitcher;
public import gtk.Statusbar;
public import gtk.StatusbarAccessible;
public import gtk.StatusIcon;
public import gtk.StockItem;
public import gtk.Style;
public import gtk.StyleContext;
public import gtk.StyleProperties;
public import gtk.StyleProviderIF;
public import gtk.StyleProviderT;
public import gtk.Switch;
public import gtk.SwitchAccessible;
public import gtk.SymbolicColor;
public import gtk.Table;
public import gtk.TargetEntry;
public import gtk.TargetList;
public import gtk.TearoffMenuItem;
public import gtk.Testing;
public import gtk.TextAttributes;
public import gtk.TextBuffer;
public import gtk.TextCellAccessible;
public import gtk.TextChildAnchor;
public import gtk.TextIter;
public import gtk.TextMark;
public import gtk.TextTag;
public import gtk.TextTagTable;
public import gtk.TextView;
public import gtk.TextViewAccessible;
public import gtk.ThemingEngine;
public import gtk.ToggleAction;
public import gtk.ToggleButton;
public import gtk.ToggleButtonAccessible;
public import gtk.ToggleToolButton;
public import gtk.Toolbar;
public import gtk.ToolButton;
public import gtk.ToolItem;
public import gtk.ToolItemGroup;
public import gtk.ToolPalette;
public import gtk.ToolShellIF;
public import gtk.ToolShellT;
public import gtk.Tooltip;
public import gtk.ToplevelAccessible;
public import gtk.TreeDragDestIF;
public import gtk.TreeDragDestT;
public import gtk.TreeDragSourceIF;
public import gtk.TreeDragSourceT;
public import gtk.TreeIter;
public import gtk.TreeIterError;
public import gtk.TreeModel;
public import gtk.TreeModelFilter;
public import gtk.TreeModelIF;
public import gtk.TreeModelSort;
public import gtk.TreeModelT;
public import gtk.TreeNode;
public import gtk.TreePath;
public import gtk.TreeRowReference;
public import gtk.TreeSelection;
public import gtk.TreeSortableIF;
public import gtk.TreeSortableT;
public import gtk.TreeStore;
public import gtk.TreeView;
public import gtk.TreeViewAccessible;
public import gtk.TreeViewColumn;
public import gtk.UIManager;
public import gtk.VBox;
public import gtk.VButtonBox;
public import gtk.Version;
public import gtk.Viewport;
public import gtk.VolumeButton;
public import gtk.VPaned;
public import gtk.VScale;
public import gtk.VScrollbar;
public import gtk.VSeparator;
public import gtk.Widget;
public import gtk.WidgetAccessible;
public import gtk.WidgetClass;
public import gtk.WidgetPath;
public import gtk.Window;
public import gtk.WindowAccessible;
public import gtk.WindowGroup;
public import gdkpixbuf.PixbufFormat;
public import gdkpixbuf.Pixdata;
public import gio.AsyncResultIF;
public import gio.Cancellable;
public import gio.IconIF;
public import gio.IconT;
public import gio.InputStream;
public import gio.LoadableIconIF;
public import gio.LoadableIconT;
public import gio.OutputStream;
public import glib.Bytes;
public import glib.ConstructionException;
public import glib.ErrorG;
public import glib.GException;
public import glib.HashTable;
public import glib.ListSG;
public import glib.Str;
public import gobject.ObjectG;
public import gtkc.gdkpixbuf;
public import gtkc.gdkpixbuftypes;


and that's just for gtk(well, mainly).
Aug 14
parent reply Johnson <Johnson Johnson.com> writes:
Not only that, but it requires adding more files to the command 
line.

I currently have 3 import files to separate the gtk from gdk that 
and the only reason they exist is to combine them in to one named 
import ;/


Doesn't seem like much but that's 3 extra files that don't really 
need to exist.

Hopefully D already implements a way to do what I'm asking.
Aug 14
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 15/08/2017 2:59 AM, Johnson wrote:
 Not only that, but it requires adding more files to the command line.
 
 I currently have 3 import files to separate the gtk from gdk that and 
 the only reason they exist is to combine them in to one named import ;/
 
 
 Doesn't seem like much but that's 3 extra files that don't really need 
 to exist.
 
 Hopefully D already implements a way to do what I'm asking.
Or instead of a new language feature, the gtk-d guys could have package files ;)
Aug 14
next sibling parent reply Johnson <Johnson Johnson.com> writes:
On Tuesday, 15 August 2017 at 03:37:39 UTC, rikki cattermole 
wrote:
 On 15/08/2017 2:59 AM, Johnson wrote:
 Not only that, but it requires adding more files to the 
 command line.
 
 I currently have 3 import files to separate the gtk from gdk 
 that and the only reason they exist is to combine them in to 
 one named import ;/
 
 
 Doesn't seem like much but that's 3 extra files that don't 
 really need to exist.
 
 Hopefully D already implements a way to do what I'm asking.
Or instead of a new language feature, the gtk-d guys could have package files ;)
But then that only helps with one specific instance. D is full of language features, I do not see why everyone is so against them. Without them, D would be empty, nothing, and no one would use it. Adding language features should be see as something good, cause without them, we wouldn't get anywhere.
Aug 15
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 15 August 2017 at 20:33:18 UTC, Johnson wrote:
 Or instead of a new language feature, the gtk-d guys could 
 have package files ;)
But then that only helps with one specific instance. D is full of language features, I do not see why everyone is so against them. Without them, D would be empty, nothing, and no one would use it. Adding language features should be see as something good, cause without them, we wouldn't get anywhere.
In the past, I've thought it would be convenient to have something like import io = std.stdio : writeln, write; and allow someone to write io.write("foo"); io.writeln("bar"); though I don't know if that causes any kinds of problems to implement. That being said, the code you refer to above probably could be simplified quite a bit with mixins. I just did a simple version, but I imagine it could be extended. It also might be even easier to accomplish when static foreach is in the language, that would you can just loop through the LowLevels to accomplish it. Some kind of hierarchy to the HighLevels/MidLevels/LowLevels would also need to be established. import std.meta : AliasSeq; alias LowLevels = AliasSeq!("writeln", "write"); template GenImport(string TopLevel, string MidLevel, string LowLevel) { const char[] GenImport = "import " ~ TopLevel ~ "." ~ MidLevel ~ " : " ~ LowLevel ~ ";"; } mixin(GenImport!("std", "stdio", LowLevels[0])); mixin(GenImport!("std", "stdio", LowLevels[1])); void main() { write("foo"); writeln("bar"); }
Aug 15
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Tuesday, 15 August 2017 at 21:12:24 UTC, jmh530 wrote:
 On Tuesday, 15 August 2017 at 20:33:18 UTC, Johnson wrote:
 Or instead of a new language feature, the gtk-d guys could 
 have package files ;)
But then that only helps with one specific instance. D is full of language features, I do not see why everyone is so against them. Without them, D would be empty, nothing, and no one would use it. Adding language features should be see as something good, cause without them, we wouldn't get anywhere.
In the past, I've thought it would be convenient to have something like import io = std.stdio : writeln, write; and allow someone to write io.write("foo"); io.writeln("bar"); though I don't know if that causes any kinds of problems to implement.
This looks really clean for code modularity. import io = std.stdio : {writeln, write}, ...
Aug 16
next sibling parent Johnson <Johnson Johnson.com> writes:
On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:
 On Tuesday, 15 August 2017 at 21:12:24 UTC, jmh530 wrote:
 On Tuesday, 15 August 2017 at 20:33:18 UTC, Johnson wrote:
 Or instead of a new language feature, the gtk-d guys could 
 have package files ;)
But then that only helps with one specific instance. D is full of language features, I do not see why everyone is so against them. Without them, D would be empty, nothing, and no one would use it. Adding language features should be see as something good, cause without them, we wouldn't get anywhere.
In the past, I've thought it would be convenient to have something like import io = std.stdio : writeln, write; and allow someone to write io.write("foo"); io.writeln("bar"); though I don't know if that causes any kinds of problems to implement.
This looks really clean for code modularity. import io = std.stdio : {writeln, write}, ...
Yes, and also import io = {std.stdio : {writeln, write}, ... } which allows one to create their own "packages" inline. Group the best functionality they use often. Should be quick, efficient, and easy to implement. D should have this, where do I vote for it?
Aug 16
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:
 This looks really clean for code modularity.

 import io = std.stdio : {writeln, write}, ...
What does this add? A line like below would be confusing. import io = std.stdio : {writeln, write}, writefln; The following code compiles and the imports are less confusing. import io = std.stdio : writeln, write; import std.stdio : writefln; void main() { io.write("foo"); io.writeln("bar"); writefln("My items are %(%s %).", [1,2,3]); }
Aug 16
parent reply aberba <karabutaworld gmail.com> writes:
On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:
 On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:
 This looks really clean for code modularity.

 import io = std.stdio : {writeln, write}, ...
What does this add? A line like below would be confusing. import io = std.stdio : {writeln, write}, writefln; The following code compiles and the imports are less confusing. import io = std.stdio : writeln, write; import std.stdio : writefln; void main() { io.write("foo"); io.writeln("bar"); writefln("My items are %(%s %).", [1,2,3]); }
Its more like this: import oo = {std.stdio : {writeln, write}, std.algorithm: {filter, map}, …}; oo.writeln(); oo.write(); oo.filter(...); oo.map(...);
Aug 17
next sibling parent Johnson Jones <JJ Dynomite.com> writes:
On Thursday, 17 August 2017 at 21:03:33 UTC, aberba wrote:
 On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:
 On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:
 This looks really clean for code modularity.

 import io = std.stdio : {writeln, write}, ...
What does this add? A line like below would be confusing. import io = std.stdio : {writeln, write}, writefln; The following code compiles and the imports are less confusing. import io = std.stdio : writeln, write; import std.stdio : writefln; void main() { io.write("foo"); io.writeln("bar"); writefln("My items are %(%s %).", [1,2,3]); }
Its more like this: import oo = {std.stdio : {writeln, write}, std.algorithm: {filter, map}, …}; oo.writeln(); oo.write(); oo.filter(...); oo.map(...);
Someone gets it! ;)
Aug 17
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 17.08.2017 23:03, aberba wrote:
 On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:
 On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:
 This looks really clean for code modularity.

 import io = std.stdio : {writeln, write}, ...
What does this add? A line like below would be confusing. import io = std.stdio : {writeln, write}, writefln; The following code compiles and the imports are less confusing. import io = std.stdio : writeln, write; import std.stdio : writefln; void main() { io.write("foo"); io.writeln("bar"); writefln("My items are %(%s %).", [1,2,3]); }
Its more like this: import oo = {std.stdio : {writeln, write}, std.algorithm: {filter, map}, …}; oo.writeln(); oo.write(); oo.filter(...); oo.map(...);
private struct oo{ import std.stdio: writeln, write; import std.algorithm: filter, map; // … } void main(){ oo.write("result: "); oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10]))); }
Aug 17
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 17 August 2017 at 21:49:38 UTC, Timon Gehr wrote:
 private struct oo{
     import std.stdio: writeln, write;
     import std.algorithm: filter, map;
     // …
 }

 void main(){
     oo.write("result: ");
     
 oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
 }
Would not have thought to do that! Very cool. Quick follow up: is there a reason this why renamed selective imports don't work this way? As in the bug from the link below we discussed above https://issues.dlang.org/show_bug.cgi?id=17756 Re-writing the import like this seems like the perfect bug fix?
Aug 17
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 18.08.2017 01:25, jmh530 wrote:
 On Thursday, 17 August 2017 at 21:49:38 UTC, Timon Gehr wrote:
 private struct oo{
     import std.stdio: writeln, write;
     import std.algorithm: filter, map;
     // …
 }

 void main(){
     oo.write("result: ");
 oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
 }
Would not have thought to do that! Very cool. Quick follow up: is there a reason this why renamed selective imports don't work this way?
I don't think there is. (I.e. I think it is indeed a bug.)
 As in the bug from the link below we discussed above
 
 https://issues.dlang.org/show_bug.cgi?id=17756
 
 Re-writing the import like this seems like the perfect bug fix?
It's one way to do it, but the compiler does not necessarily need to generate a new type. Note that unfortunately, renamed imports don't overload, so this would not work even with the fixed bug: import oo=std.stdio: writeln, write; import oo=std.algorithm: filter, map; // error: oo redefined void main(){ oo.write("result: "); oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10]))); } I think this is working as designed, but IMO they should just overload (using distinct overload sets so the semantics is similar to the case when using the struct), as should named mixins.
Aug 18
prev sibling parent reply Johnson Jones <JJ Dynomite.com> writes:
On Thursday, 17 August 2017 at 21:49:38 UTC, Timon Gehr wrote:
 On 17.08.2017 23:03, aberba wrote:
 On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:
 On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:
 This looks really clean for code modularity.

 import io = std.stdio : {writeln, write}, ...
What does this add? A line like below would be confusing. import io = std.stdio : {writeln, write}, writefln; The following code compiles and the imports are less confusing. import io = std.stdio : writeln, write; import std.stdio : writefln; void main() { io.write("foo"); io.writeln("bar"); writefln("My items are %(%s %).", [1,2,3]); }
Its more like this: import oo = {std.stdio : {writeln, write}, std.algorithm: {filter, map}, …}; oo.writeln(); oo.write(); oo.filter(...); oo.map(...);
private struct oo{ import std.stdio: writeln, write; import std.algorithm: filter, map; // … } void main(){ oo.write("result: "); oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10]))); }
Wow, that might solve the problem! A little more verbose but it does combine everything. Any downsides? Thanks.
Aug 17
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 18.08.2017 03:11, Johnson Jones wrote:

 private struct oo{
     import std.stdio: writeln, write;
     import std.algorithm: filter, map;
     // …
 }

 void main(){
     oo.write("result: ");
 oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
 }
Wow, that might solve the problem! A little more verbose but it does combine everything. Any downsides?
- It is more verbose. ;) - IMAO it shouldn't even work without 'public' on the imports. (So if someone decides to fix that it might break and become more verbose.) - It introduces a new type that would not really be necessary. This is avoidable, at the cost of a little more verbosity: private template Imports(){ public import std.stdio: writeln, write; public import std.algorithm: filter, map; } private alias oo = Imports!(); void main(){ oo.write("result: "); oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10]))); } The pattern can be abstracted into a utility template: --- module util; // ... template Imports(T...){ import std.string,std.algorithm; mixin([T].map!(x=>"public import "~x~";").join); // or, starting from DMD 2.076, you could use static foreach instead: // static foreach(x;T) mixin("public import "~x~";"); } // ... --- --- module main; import util: Imports; private alias oo = Imports!( `std.stdio: writeln, write`, `std.algorithm: filter, map` ); void main(){ oo.write("result: "); oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10]))); } ---
 Thanks.
np.
Aug 18
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 18 August 2017 at 09:18:42 UTC, Timon Gehr wrote:
 ---
 module util;

 // ...

 template Imports(T...){
     import std.string,std.algorithm;
     mixin([T].map!(x=>"public import "~x~";").join);
     // or, starting from DMD 2.076, you could use static 
 foreach instead:
     // static foreach(x;T) mixin("public import "~x~";");
 }

 // ...
The static foreach is nice...doesn't depend on phobos.
Aug 18
prev sibling parent Olivier FAURE <olivier.faure epitech.eu> writes:
On Friday, 18 August 2017 at 09:18:42 UTC, Timon Gehr wrote:
 Any downsides?
 
... - It introduces a new type that would not really be necessary. This is avoidable, at the cost of a little more verbosity:
D newbie here: is there a non-negligible cost to creating a stateless struct type? Also, since the struct is private and only used for its aliases, if there a chance the compiler might elide those costs?
Aug 18
prev sibling parent reply Joel Nilsson <nilserikjoel96 hotmail.com> writes:
On Tuesday, 15 August 2017 at 21:12:24 UTC, jmh530 wrote:
 In the past, I've thought it would be convenient to have 
 something like

 import io = std.stdio : writeln, write;

 and allow someone to write

 io.write("foo");
 io.writeln("bar");
This is already in the language: http://dlang.org/spec/module.html#renamed_imports
Aug 16
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 16 August 2017 at 10:12:01 UTC, Joel Nilsson wrote:
 On Tuesday, 15 August 2017 at 21:12:24 UTC, jmh530 wrote:
 In the past, I've thought it would be convenient to have 
 something like

 import io = std.stdio : writeln, write;

 and allow someone to write

 io.write("foo");
 io.writeln("bar");
This is already in the language: http://dlang.org/spec/module.html#renamed_imports
Well I knew that renamed imports were allowed, but I didn't realize you could do re-named selective imports (the " : writeln, write" part of it). I just double-checked and it worked. I don't recall it working in the past. I see that there's an example in the spec, but it is a little more complicated than my example.
Aug 16
parent reply rjframe <dlang ryanjframe.com> writes:
On Wed, 16 Aug 2017 12:04:13 +0000, jmh530 wrote:
 
 Well I knew that renamed imports were allowed, but I didn't realize you
 could do re-named selective imports (the " : writeln,
 write" part of it). I just double-checked and it worked. I don't recall
 it working in the past.
 
 I see that there's an example in the spec, but it is a little more
 complicated than my example.
It doesn't quite work; it provides access to all names in the module, and write/writeln is introduced into the global namespace; e.g., it's interpreted as `import io = std.stdio; import std.stdio : write, writeln;` https://issues.dlang.org/show_bug.cgi?id=17756
Aug 17
parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 17 August 2017 at 11:40:11 UTC, rjframe wrote:
 It doesn't quite work; it provides access to all names in the 
 module, and
 write/writeln is introduced into the global namespace; e.g., 
 it's
 interpreted as
 `import io = std.stdio; import std.stdio : write, writeln;`

 https://issues.dlang.org/show_bug.cgi?id=17756
Yeah, I wouldn't have expected the following code to compile without error import io = std.stdio : writeln; void main() { io.write("foo"); //expect error here, but none writeln("blah"); //expect error here, but none io.writeln("bar"); //no error }
Aug 17
prev sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 15 August 2017 at 20:33:18 UTC, Johnson wrote:
 On Tuesday, 15 August 2017 at 03:37:39 UTC, rikki cattermole 
 wrote:
 But then that only helps with one specific instance. D is full 
 of language features, I do not see why everyone is so against 
 them. Without them, D would be empty, nothing, and no one would 
 use it. Adding language features should be see as something 
 good, cause without them, we wouldn't get anywhere.
Its an important challenge of software development, and a number of articles out there about it. https://www.google.com/search?q=the+cost+of+features&ie=utf-8&oe=utf-8 At first glance I wasn't finding anything which uniquely tackles compilers and languages. Backwards compatibility isn't just for programming languages but can be more important. A good UI can help a user with complexity. So does consistency. Adding a syntax for special meaning can be difficult to remember. My personal example is properties in C#. The syntax is straight forward and clean, but only recently have I been able to remember how to write one: ReturnType Name { get { return a; } set(value) { a = value; } } As for your specific suggestion I think it would be nice at times but the complexity you haven't specified is how do deal with ambiguities if two modules provide the same symbol name. D may have a number of features which C++ doesn't and visa versa, the complexity of the language for C++ to have those features means I work with D and not C++.
Aug 16
parent reply Johnson Jones <JJ Dynomite.com> writes:
On Wednesday, 16 August 2017 at 19:05:54 UTC, Jesse Phillips 
wrote:
 On Tuesday, 15 August 2017 at 20:33:18 UTC, Johnson wrote:
 On Tuesday, 15 August 2017 at 03:37:39 UTC, rikki cattermole 
 wrote:
 But then that only helps with one specific instance. D is full 
 of language features, I do not see why everyone is so against 
 them. Without them, D would be empty, nothing, and no one 
 would use it. Adding language features should be see as 
 something good, cause without them, we wouldn't get anywhere.
Its an important challenge of software development, and a number of articles out there about it. https://www.google.com/search?q=the+cost+of+features&ie=utf-8&oe=utf-8 At first glance I wasn't finding anything which uniquely tackles compilers and languages. Backwards compatibility isn't just for programming languages but can be more important.
Yes, but you are choosing a side, like most people. What about the cost of not advancing? How many man hours are wasted because someone won't implement feature because they "think" it will cause problems or because they are too lazy or won't get enough $$$ to do it? Cost is not a one way street. When you don't do something it is doing something. The whole problem with backwards compatibility is that it is based on ignorance. When computers were first hitting the street, people were doing what I am suggesting, as that's all they could do. They screwed up a lot of things and wasted a lot of time. But then 50 years later people use that as an example, out of ignorance, to suggest that the same mistakes will occur. They completely neglect the fact that we wouldn't have what we have without all those mistakes either. You can argue all you want, until you are purple in the face, but you cannot deny what I have said as being the truth and your arguments are baseless for the same reasons you claim mine is. If one had to do things blindly and ignorantly, then yes, your arguments are sound. But by using your brain, learning from past mistakes, and moving forward to make progress, the issues can be minimized and a balanced can be made. You cannot apply some general statement to all specific instances unless that statement is truly general. The backwards compatibility plague is based on ignorance, e.g., "We don't know what will be the ramifications of doing X so we will stick with the status quo!". That is a purely ignorant statement, that is, it is saying the same as "We are ignorant of what will happen if we do X so we won't do anything". When you apply that logic to something that one doesn't have to be ignorant of, one is missing out on doing X and if X is good and done and improves things then it is a same and real ignorance wins again. No progress could ever be made if people didn't try things. If people try things intelligent then they minimize the problems that people like you are afraid of. The best solution is a balance, wouldn't you agree? When a "feature" offers no foreseeable issues(essentially nearly mathematically proved to be correct), then it shouldn't be looked as bad. Again, as I pointed out, where would anything be if everyone had the mentality you state? Would D have mixins? No, because who knows what kinda problems they could introduce in the language? Would D have traits? No, because who knows what kinda problems they could introduce in the language? etc... etc.. etc.. etc.. And these cause problems not just in programming but in real life. No one wants to fix the problems, say, of America because who knows what kinda problems that will introduce... and given the track record of those that do the "problem fixing" we can be pretty sure of the outcome. But the problem is then not the problem fixing but those that fix the problems. So, my point is that your argument is baseless and doesn't mean anything in the real world. It is a guide, a parable about the past and potentially the future, but people like you seem to like to make it a law, like gravity, which it is not. The sad fact is that it slows down real progress. One could make arguments about and if progress is a good thing or not in and of itself, but that is a different issue.
 A good UI can help a user with complexity. So does consistency. 
 Adding a syntax for special meaning can be difficult to 
 remember. My personal example is properties in C#. The syntax 
 is straight forward and clean, but only recently have I been 
 able to remember how to write one: ReturnType Name { get { 
 return a; } set(value) { a = value; } }
 As for your specific suggestion I think it would be nice at 
 times but the complexity you haven't specified is how do deal 
 with ambiguities if two modules provide the same symbol name.

 D may have a number of features which C++ doesn't and visa 
 versa, the complexity of the language for C++ to have those 
 features means I work with D and not C++.
Then why are you so against adding features? That is what made D better than C++? Walter could have said to himself: "I'm not going to implement this feature that C++ doesn't have because it will break backwards compatibility", but he didn't. He tried something he thought would work because he reasoned it would. He didn't make a blind ignorant leap of faith that you are claiming is done anytime on wants to change something. It was based on experience and reason. If you can find a specific reason why having such a notation is wrong then that would be a valid point, but generalities that don't apply is not helpful to the cause. As far as your argument about ambiguities, that already exists, so it is not a problem with a new feature that extends what we have(it might inherit the problem, but it is not the cause of it). So, you should talk to walter about fixing that. Do you understand? I have no issues with trying to defend the logic of something I say should be implemented, but you have to use proper logic itself instead of going with your gut and then creating baseless arguments against it. My main argument is that your two arguments: 1. Adding language features is bad. 2. The proposed idea creates the issue of ambiguity between identical symbols. My logical argument against yours: 1. It is irrelevant and has nothing to do with anything. It may or may not be a valid argument in some sense but it is just a safety net/guide rail and by no means used to judge the validity of something. (one can't really reason anything from that argument because as much as it is right it is also wrong) 2. The ambiguity is, at it's root, part of D's module system design and part of D's problem, not the addition of something new on top of it. It cannot be fixed by not adding the addition and can't be fixed by choosing not to have it. So it too is irrelevant. If, it were to complicate the addition and make the addition have new problems, then that is a valid argument, but that is something you have to prove or show, which you haven't done. So what I have ended up doing, rather than really defend my proposal for what it is and does, is have to correct your logic so that maybe we hopefully get somewhere. Note that none of this is an attack on you so don't get upset. I simply would like to see this feature get implemented if it is a good idea, and if it not, then I don't want it to... but before we can determine that in a correct way, we first have to judge it for what it is rather than what it is not. To even make it clearer: You mention your problem with C#'s properties. Your logic is that they shouldn't be implemented the way they are because it confuses you. That is not logical. I got the properties in 2ms because I realize it is just a definition. It is your ignorance(not a personal attack, we are all ignorant, but you are ignorant in that thing which causes you not to get it, which I wasn't... not because I'm better than you are smarter, but because I'm different) that prevents you from doing, not a defect in the properties. But instead of you finding that thing that makes it difficult for you to get, you want to slow everyone else down and make them use the same thing that works for you(which might not work for them)... but in any case, it is not logical, it is an argument based on ignorance. In fact, I like they say C# does it and it makes complete sense to me... in fact, many things that C# does makes sense and the only reason I don't use it is because of the CLR/IR type of stuff that becomes a hindrance for many things I do. IMO C# is the best designed language I've ever seen out of about 30 languages I've used. (from assembly to pascal, to eel, to D) But all that is irrelevant, the map is not the territory. My arguments are about the territory while yours, so far is about the map. Hopefully you can get that so we can move on to both at least be on the same topic. BTW, I'm not in to maps because I think they are irrelevant made up BS and basically based on humans ignorance and are the real waste of time. (And hopefully by maps you realize I'm not talking about real geographical maps)
Aug 16
parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
This was hard to keep reading, but ultimately enjoyable, because 
your arguments stem from interpretations and opinions of my point 
rather than the points I was making.

It is interesting that you feel I've claimed your point is 
baseless when I made no attempt to say such. Would help if I 
confirm that you do have valid arguments?

I provided a general response to a general question. You asked 
why people would be against features, which in your response has 
changed it to why people would be against features nearly 
mathematically proven to be correct.

I'm not saying we shouldn't look at the feature suggestion and 
way the pros and cons, but when you make a statement like "Adding 
language features should be see as something good, cause without 
them, we wouldn't get anywhere." it sounds more like your stating 
"Language features provide benefits, ignore the harm they cause 
it can't out weigh the harm it does."

On Wednesday, 16 August 2017 at 22:19:31 UTC, Johnson Jones wrote:
 Cost is not a one way street. When you don't do something it is 
 doing something.  The whole problem with backwards 
 compatibility is that it
 is based on ignorance.
But it isn't, your examples are all new, unestablished products which have no market to keep. There is a reason C++, Java, C#, C, Go, and countless other products keep backwards compatibility and it has nothing to do with ignorance. There is evidence even within the D community and Python, that breaking backwards compatibility does enough harm that it could be argued the change wasn't worth it (especially if done routinely).
 D may have a number of features which C++ doesn't and visa 
 versa, the complexity of the language for C++ to have those 
 features means I work with D and not C++.
Then why are you so against adding features? That is what made D better than C++?
I didn't say that D features made it better than C++. I did say that the complexity of C++ has kept me away from it.
 If you can find a specific reason why having such a notation is 
 wrong then that would be a valid point, but generalities that 
 don't apply is not helpful to the cause.
I did which you know since that is the very next thing you touch on.
 As far as your argument about ambiguities, that already exists, 
 so it is not a problem with a new feature that extends what we 
 have(it might inherit the problem, but it is not the cause of 
 it). So, you should talk to walter about fixing that.
But ambiguities don't exist. If I name an import the compiler knows exactly which symbols I'm referring to. In fact named imports is one of the solutions Walter put in place to fix the ambiguity problem which you're now wanting to introduce into one of the approaches to solving the problem.
 My main argument is that your two arguments: 1. Adding language 
 features is bad. 2. The proposed idea creates the issue of 
 ambiguity between identical symbols.
But I didn't make the argument that "adding language features is bad." I made the argument that "adding language features has a cost." And to be more explicit, "it has a cost and you should be aware of the cost making the choices based on what the pros are with the costs and the weight of those pros and costs."
 2. The ambiguity is, at it's root, part of D's module system 
 design and part of D's problem, not the addition of something 
 new on top of it. It cannot be fixed by not adding the addition 
 and can't be fixed by choosing not to have it. So it too is 
 irrelevant. If, it were to complicate the addition and make the 
 addition have new problems, then that is a valid argument, but 
 that is something you have to prove or show, which you haven't 
 done.
D has facilities for handling ambiguity, it is at the root of D, part of D's module system design. This argument only shows you are not aware or understand D's approach to solving the problem.
 So what I have ended up doing, rather than really defend my 
 proposal for what it is and does, is have to correct your logic 
 so that maybe we hopefully get somewhere. Note that none of 
 this is an attack on you so don't get upset.  I simply would 
 like to see this feature get implemented if it is a good idea, 
 and if it not, then I don't want it to... but before we can 
 determine that in a correct way, we first have to judge it for 
 what it is rather than what it is not.
Right, that is why I started with the general arguments, we have to be using the same decision making logic. Your view of features suggested that your approach to decision making differs from that of the top D contributors and a portion of the community. My logic could be wrong, but reflecting back to my first paragraph, you aren't going to be able to correct my logic if you don't understand what that logic is and instead go on a rampage of a view some fictitious person has in your head.
Aug 17
prev sibling parent reply Gary Willoughby <dev nomad.so> writes:
On Tuesday, 15 August 2017 at 03:37:39 UTC, rikki cattermole 
wrote:
 On 15/08/2017 2:59 AM, Johnson wrote:
 Not only that, but it requires adding more files to the 
 command line.
 
 I currently have 3 import files to separate the gtk from gdk 
 that and the only reason they exist is to combine them in to 
 one named import ;/
 
 
 Doesn't seem like much but that's 3 extra files that don't 
 really need to exist.
 
 Hopefully D already implements a way to do what I'm asking.
Or instead of a new language feature, the gtk-d guys could have package files ;)
This! Just create a PR for Gtk-D to add packages.
Aug 16
parent reply Mike Wey <mike-wey example.com> writes:
On 16-08-17 09:58, Gary Willoughby wrote:
 On Tuesday, 15 August 2017 at 03:37:39 UTC, rikki cattermole wrote:
 On 15/08/2017 2:59 AM, Johnson wrote:
 Not only that, but it requires adding more files to the command line.

 I currently have 3 import files to separate the gtk from gdk that and 
 the only reason they exist is to combine them in to one named import ;/


 Doesn't seem like much but that's 3 extra files that don't really 
 need to exist.

 Hopefully D already implements a way to do what I'm asking.
Or instead of a new language feature, the gtk-d guys could have package files ;)
This! Just create a PR for Gtk-D to add packages.
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. -- Mike Wey
Aug 16
parent reply jmh530 <john.michael.hall gmail.com> writes:
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.
Aug 16
parent reply Johnson Jones <JJ Dynomite.com> writes:
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.
Aug 16
parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 16 August 2017 at 18:38:23 UTC, Johnson Jones wrote:
 Not really, I'm not doing selective imports.
 [snip]
I'll preface this by saying that I think Jesse Phillips' point is a good one. The fact that you can already do it with the language (as you note about having a separate file full of imports) suggests that it doesn't have much chance of being part of the language. Moving on to your point about wildcards, isn't that what package.d is for? I agree with the others that a lot of the pain would be reduced gtkd had package.d files set up. Nevertheless, you also seem to want to be able to import a limited number of modules of a package and rename them one thing. Here's an example that I think illustrates your point with phobos: import foo = std.algorithm.searching, std.algorithm.comparison; void main() { int[] a = [ 1, 2, 4, 3, 2, 5, 3, 2, 4 ]; auto val = foo.count(a, 2); auto result = cmp("abc", "abc"); } In this, you can have count named with foo, but you can't name cmp with foo. Of course, this isn't a problem with selective imports if there is a package.d file. I found some interesting stuff on bugzilla related to this stuff https://issues.dlang.org/show_bug.cgi?id=3603 https://issues.dlang.org/show_bug.cgi?id=12359 The first one has a recommendation to allow something like (and actually the initial suggestion has a version quite similar to yours): import std.algorithm : searching, comparison; which is currently not allowed, and would require some changes to how imports work to get it included in the language. However, it is very similar to what you are looking for (why I was so focused on selective imports), except that it does not have renaming, so you'd prefer something like import foo = std.algorithm : searching, comparison; The most significant difference between this and what you are suggesting is that your approach is probably more general. You could put anything between the { }, whereas this approach is a bit more limited. It might the things a little easier to distinguish between a module import and a symbol import (like import std.algorithm :: searching, comparison : count, cmp; instead).
Aug 16