Re: Named multi-imports
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?
Re: Named multi-imports
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.
Re: Named multi-imports
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.
Re: Named multi-imports
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.
Re: Named multi-imports
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.
Re: Named multi-imports
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?
Re: Named multi-imports
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])));
}
Re: Named multi-imports
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! ;)
Re: Named multi-imports
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(...);
Re: New Features [was Named multi-imports]
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.
Re: Named multi-imports
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
}
Re: Named multi-imports
On Wed, 16 Aug 2017 12:04:13 +, 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
Re: New Features [was Named multi-imports]
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 m
Re: Named multi-imports
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).
New Features [was Named multi-imports]
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++.
Re: Named multi-imports
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.
Re: Named multi-imports
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.
Re: Named multi-imports
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
Re: Named multi-imports
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]);
}
Re: Named multi-imports
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?
Re: Named multi-imports
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.
Re: Named multi-imports
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
Re: Named multi-imports
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}, ...
Re: Named multi-imports
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.
Re: Named multi-imports
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");
}
Re: Named multi-imports
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.
Re: Named multi-imports
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 ;)
Re: Named multi-imports
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.
Named multi-imports
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
