On Fri, 06 Apr 2012 20:25:23 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
DIP15 doesn't fix the explicit path problem though. You can't change
std/algorithm.d into std/algorithm/ (with sorting.d, search.d, etc.)
without
breaking code. You could make std/algorithm.d publicly import
On Monday, April 09, 2012 08:55:27 Steven Schveighoffer wrote:
On Fri, 06 Apr 2012 20:25:23 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
DIP15 doesn't fix the explicit path problem though. You can't change
std/algorithm.d into std/algorithm/ (with sorting.d, search.d, etc.)
without
On 2012-04-07 02:25, Jonathan M Davis wrote:
On Friday, April 06, 2012 08:09:28 Steven Schveighoffer wrote:
I feel like most people will still import the main package module, and not
the submodules. I don't think I ever wrote a piece of java code that
didn't have:
import java.io.*;
Which is
On Saturday, April 07, 2012 18:45:15 Jacob Carlborg wrote:
On 2012-04-07 02:25, Jonathan M Davis wrote:
On Friday, April 06, 2012 08:09:28 Steven Schveighoffer wrote:
I feel like most people will still import the main package module, and
not
the submodules. I don't think I ever wrote a
On Saturday, 7 April 2012 at 17:44:20 UTC, Jonathan M Davis wrote
Like I said, some people do like to do it, but Eclipse doesn't
like you to,
and there are quite a few Java folks who argue that it's bad
practice. I
forget what the reasons were (maybe increased buld times due to
pulling in
Le 05/04/2012 23:43, Andrei Alexandrescu a écrit :
On 4/5/12 4:26 PM, Steven Schveighoffer wrote:
On Thu, 05 Apr 2012 17:00:56 -0400, Jonathan M Davis
jmdavisp...@gmx.com wrote:
On Thursday, April 05, 2012 15:30:17 Steven Schveighoffer wrote:
I don't see how. Just move the code into
Le 06/04/2012 01:32, Michel Fortin a écrit :
On 2012-04-05 21:43:24 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
I think we should be looking for a solution that not only allows
replacing module - package transparently, but also allows people to
import the newly introduced
On Thu, 05 Apr 2012 23:18:07 -0400, Ary Manzana a...@esperanto.org.ar
wrote:
On 4/5/12 10:55 PM, Steven Schveighoffer wrote:
On Fri, 30 Mar 2012 10:46:19 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Starting a new thread from one in announce:
On Thu, 05 Apr 2012 19:14:42 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, April 05, 2012 17:33:50 Steven Schveighoffer wrote:
Why do we ever need to split modules for documentation? Just fix the doc
generator so it's not as monolithic. For instance, have one page per
On Thu, 05 Apr 2012 17:43:24 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 4/5/12 4:26 PM, Steven Schveighoffer wrote:
On Thu, 05 Apr 2012 17:00:56 -0400, Jonathan M Davis
jmdavisp...@gmx.com wrote:
On Thursday, April 05, 2012 15:30:17 Steven Schveighoffer wrote:
I
On 2012-04-06 09:41:27 +, deadalnix deadal...@gmail.com said:
Why not limit name collision to name which make sense ?
You're proposing that fully qualified names sometime work and sometime
do not work based on what you've imported and the context of usage.
This makes any FQN conflict
On 4/6/12 4:43 AM, deadalnix wrote:
Le 06/04/2012 01:32, Michel Fortin a écrit :
On 2012-04-05 21:43:24 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
I think we should be looking for a solution that not only allows
replacing module - package transparently, but also allows
Le 06/04/2012 16:49, Andrei Alexandrescu a écrit :
On 4/6/12 4:43 AM, deadalnix wrote:
Le 06/04/2012 01:32, Michel Fortin a écrit :
On 2012-04-05 21:43:24 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
I think we should be looking for a solution that not only allows
replacing
On 4/6/12 10:52 AM, deadalnix wrote:
Good point. That is an argument for package.d, all.d or _.d .
Or [packagename].d, where [packagename] is the name of its sibling
folder (std/algorithm.d in the case of std/algorithm/sort.d).
Le 06/04/2012 20:03, David Gileadi a écrit :
On 4/6/12 10:52 AM, deadalnix wrote:
Good point. That is an argument for package.d, all.d or _.d .
Or [packagename].d, where [packagename] is the name of its sibling
folder (std/algorithm.d in the case of std/algorithm/sort.d).
No, because in
On Friday, April 06, 2012 08:09:28 Steven Schveighoffer wrote:
I feel like most people will still import the main package module, and not
the submodules. I don't think I ever wrote a piece of java code that
didn't have:
import java.io.*;
Which is actually considered bad practice in Java,
On Friday, April 06, 2012 07:56:41 Steven Schveighoffer wrote:
On Thu, 05 Apr 2012 19:14:42 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, April 05, 2012 17:33:50 Steven Schveighoffer wrote:
Why do we ever need to split modules for documentation? Just fix the doc
Le 05/04/2012 02:55, Martin Nowak a écrit :
What happen if both pkg.d and pkg/_.d exists ? If it is not in the
same path (think -I compiler option). In one case, this is an issue,
in the other this isn't.
pkg.d would always be a module, hence result in a module/package conflict.
We'd need to
On Wed, 04 Apr 2012 20:50:49 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2012-04-04 19:48:32 +, Steven Schveighoffer
schvei...@yahoo.com said:
On Wed, 04 Apr 2012 14:03:07 -0400, Timon Gehr timon.g...@gmx.ch
wrote:
No symbol is resolved until semantic, but I don't
On Thu, 05 Apr 2012 08:49:24 -0400, deadalnix deadal...@gmail.com wrote:
If such a syntax is adopted, what would be the point of public imports ?
If it is still useful, then your syntax is a better choice, otherwise,
we'd better modify public import.
Another way to look at it:
A public
On 04/05/2012 02:58 PM, Steven Schveighoffer wrote:
No, public imports simply mean that you can view the publicly imported
module. It does *not* add aliases to the importing module.
Have you tried it?
On Thu, 05 Apr 2012 09:23:25 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 04/05/2012 02:58 PM, Steven Schveighoffer wrote:
No, public imports simply mean that you can view the publicly imported
module. It does *not* add aliases to the importing module.
Have you tried it?
I just did. OK,
Le 05/04/2012 14:58, Steven Schveighoffer a écrit :
On Thu, 05 Apr 2012 08:49:24 -0400, deadalnix deadal...@gmail.com wrote:
Le 05/04/2012 13:46, Steven Schveighoffer a écrit :
I don't like this proposal, simply because this means one
function/symbol per submodule. It should be more flexible
On 2012-04-05 11:46:38 +, Steven Schveighoffer
schvei...@yahoo.com said:
I don't like this proposal, simply because this means one function/symbo l
per submodule. It should be more flexible than that. But I like the li ne
of thinking.
I have the same reserve about it's lack of
On 4/4/12 10:53 AM, Steven Schveighoffer wrote:
On Wed, 04 Apr 2012 12:33:26 -0400, Michel Fortin
michel.for...@michelf.com wrote:
Question 2: does std.algorithm.sort refer to the std.algorithm.sort
*module* or to std.algorithm.package.sort *function* publicly imported
from the
On Thu, 05 Apr 2012 10:26:16 -0400, deadalnix deadal...@gmail.com wrote:
Le 05/04/2012 14:58, Steven Schveighoffer a écrit :
On Thu, 05 Apr 2012 08:49:24 -0400, deadalnix deadal...@gmail.com
wrote:
Le 05/04/2012 13:46, Steven Schveighoffer a écrit :
No, public imports simply mean that you
On Thu, 05 Apr 2012 10:35:52 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 4/4/12 10:53 AM, Steven Schveighoffer wrote:
On Wed, 04 Apr 2012 12:33:26 -0400, Michel Fortin
michel.for...@michelf.com wrote:
Question 2: does std.algorithm.sort refer to the std.algorithm.sort
Le 05/04/2012 16:35, Andrei Alexandrescu a écrit :
On 4/4/12 10:53 AM, Steven Schveighoffer wrote:
On Wed, 04 Apr 2012 12:33:26 -0400, Michel Fortin
michel.for...@michelf.com wrote:
Question 2: does std.algorithm.sort refer to the std.algorithm.sort
*module* or to std.algorithm.package.sort
On Thu, 05 Apr 2012 10:33:14 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2012-04-05 11:46:38 +, Steven Schveighoffer
schvei...@yahoo.com said:
I don't like this proposal, simply because this means one
function/symbo l
per submodule. It should be more flexible than that.
Le 05/04/2012 16:47, Steven Schveighoffer a écrit :
But for moving a module like std.algorithm to a package, it's cumbersome.
Not really. Just move the files to another directory (i.e.
std/internal/algorithm) and publicly import them.
std/internal isn't good. If I just want to import sort,
On Thu, 05 Apr 2012 10:53:34 -0400, deadalnix deadal...@gmail.com wrote:
Le 05/04/2012 16:47, Steven Schveighoffer a écrit :
But for moving a module like std.algorithm to a package, it's
cumbersome.
Not really. Just move the files to another directory (i.e.
std/internal/algorithm) and
On Thu, 05 Apr 2012 10:59:31 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Thu, 05 Apr 2012 10:53:34 -0400, deadalnix deadal...@gmail.com
wrote:
Le 05/04/2012 16:47, Steven Schveighoffer a écrit :
Not really. Just move the files to another directory (i.e.
On Thu, 05 Apr 2012 10:59:31 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Thu, 05 Apr 2012 10:53:34 -0400, deadalnix deadal...@gmail.com
wrote:
Plus, the package accessibility modifier would be broken with such a
pattern.
The all.d, package.d, _.d, or, as I propose
On 4/5/12 7:43 AM, Steven Schveighoffer wrote:
I currently think DIP16 is invalid/worksforme (public imports allows
splitting a module into a package). All that is left is how we could
specifically import a package with one import statement.
Not entirely (I was aware of the way public import
On Thu, 05 Apr 2012 11:23:12 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 4/5/12 7:43 AM, Steven Schveighoffer wrote:
I currently think DIP16 is invalid/worksforme (public imports allows
splitting a module into a package). All that is left is how we could
specifically
Le 05/04/2012 17:23, Andrei Alexandrescu a écrit :
On 4/5/12 7:43 AM, Steven Schveighoffer wrote:
I currently think DIP16 is invalid/worksforme (public imports allows
splitting a module into a package). All that is left is how we could
specifically import a package with one import statement.
On Thursday, April 05, 2012 09:49:59 Steven Schveighoffer wrote:
On Thu, 05 Apr 2012 09:23:25 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 04/05/2012 02:58 PM, Steven Schveighoffer wrote:
No, public imports simply mean that you can view the publicly imported
module. It does *not* add
On Thursday, April 05, 2012 11:30:26 Steven Schveighoffer wrote:
A couple issues that still need consideration:
1. If std.algorithm the module becomes std.algorithm the package, what
happens with ddoc? We probably *do* need a compiler solution to this.
That's assuming that you insist on
On Thu, 05 Apr 2012 14:33:22 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, April 05, 2012 11:30:26 Steven Schveighoffer wrote:
A couple issues that still need consideration:
1. If std.algorithm the module becomes std.algorithm the package, what
happens with ddoc? We
On Thu, 05 Apr 2012 14:24:10 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, April 05, 2012 09:49:59 Steven Schveighoffer wrote:
On Thu, 05 Apr 2012 09:23:25 -0400, Timon Gehr timon.g...@gmx.ch I
suppose the only thing we don't get is being able to have a module and a
On Thursday, April 05, 2012 15:30:17 Steven Schveighoffer wrote:
On Thu, 05 Apr 2012 14:24:10 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, April 05, 2012 09:49:59 Steven Schveighoffer wrote:
On Thu, 05 Apr 2012 09:23:25 -0400, Timon Gehr timon.g...@gmx.ch I
suppose the
On Thursday, April 05, 2012 15:26:14 Steven Schveighoffer wrote:
On Thu, 05 Apr 2012 14:33:22 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, April 05, 2012 11:30:26 Steven Schveighoffer wrote:
A couple issues that still need consideration:
1. If std.algorithm the
On Thu, 05 Apr 2012 17:00:56 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, April 05, 2012 15:30:17 Steven Schveighoffer wrote:
I don't see how. Just move the code into another module and publicly
import that module from std/algorithm.d. Problem pretty much solved.
The
On Thu, 05 Apr 2012 17:02:13 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, April 05, 2012 15:26:14 Steven Schveighoffer wrote:
On Thu, 05 Apr 2012 14:33:22 -0400, Jonathan M Davis
jmdavisp...@gmx.com
wrote:
On Thursday, April 05, 2012 11:30:26 Steven Schveighoffer
On 4/5/12 4:26 PM, Steven Schveighoffer wrote:
On Thu, 05 Apr 2012 17:00:56 -0400, Jonathan M Davis
jmdavisp...@gmx.com wrote:
On Thursday, April 05, 2012 15:30:17 Steven Schveighoffer wrote:
I don't see how. Just move the code into another module and publicly
import that module from
On Thursday, April 05, 2012 17:33:50 Steven Schveighoffer wrote:
On Thu, 05 Apr 2012 17:02:13 -0400, Jonathan M Davis jmdavisp...@gmx.com
If the module isn't large enough to be split for documentation, I find
it hard
to believe that it needs to be split for maintenance.
Why do we ever
On Thursday, April 05, 2012 16:43:24 Andrei Alexandrescu wrote:
On 4/5/12 4:26 PM, Steven Schveighoffer wrote:
On Thu, 05 Apr 2012 17:00:56 -0400, Jonathan M Davis
jmdavisp...@gmx.com wrote:
On Thursday, April 05, 2012 15:30:17 Steven Schveighoffer wrote:
I don't see how. Just move the
On 2012-04-05 21:43:24 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
I think we should be looking for a solution that not only allows
replacing module - package transparently, but also allows people to
import the newly introduced fine-grained modules.
I think it'd be
Le 03/04/2012 19:44, Martin Nowak a écrit :
On Fri, 30 Mar 2012 16:46:19 +0200, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Starting a new thread from one in announce:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
Please comment, after which Walter will approve.
On Mon, 02 Apr 2012 20:44:09 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2012-04-02 13:04:31 +, Steven Schveighoffer
schvei...@yahoo.com said:
On Fri, 30 Mar 2012 17:45:36 -0400, Michel Fortin
The problem is that if .std.algorithm.package
contains a sort function and
On 2012-04-04 14:08:34 +, Steven Schveighoffer
schvei...@yahoo.com said:
On Mon, 02 Apr 2012 20:44:09 -0400, Michel Fortin
michel.for...@michelf.com wrote:
Whereas if the fully-qualified name of a module becomes ambiguous
because of a symbol in another module, there is no way to
On Wed, 04 Apr 2012 12:33:26 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2012-04-04 14:08:34 +, Steven Schveighoffer
schvei...@yahoo.com said:
The FQN cannot be ambiguous.
Sure it can if I follow DIP16, because module names can become ambiguous.
Let's try this with an
On 2012-04-04 18:33, Michel Fortin wrote:
You might think I'm trying to split hair in four to find flaws, that no
one is going to do things that dumb, but I unfortunately think the
problematic pattern is already quite common. How many times have we seen
modules containing a class, variable, or
On Wed, 04 Apr 2012 14:03:07 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 04/04/2012 07:53 PM, Steven Schveighoffer wrote:
OK, but when is it ever valid to refer to a module when the semantic
expectations are for something other than a module? I can only think of
two places where module names
On 2012-04-04 17:53:24 +, Steven Schveighoffer
schvei...@yahoo.com said:
But yes, I think the issue really becomes, we need to look at context
when deciding the semantic meaning of a symbol. I don't think this
violates the context-free grammar, because wouldn't this only come
into
On 2012-04-04 19:48:32 +, Steven Schveighoffer
schvei...@yahoo.com said:
On Wed, 04 Apr 2012 14:03:07 -0400, Timon Gehr timon.g...@gmx.ch wrote:
No symbol is resolved until semantic, but I don't think hiding the
module/package symbol if any clashing symbol in the module/any
subpackage
What happen if both pkg.d and pkg/_.d exists ? If it is not in the same
path (think -I compiler option). In one case, this is an issue, in the
other this isn't.
pkg.d would always be a module, hence result in a module/package conflict.
We'd need to directly search for a subdirectory to decide
On 2012-04-05 00:50:49 +, Michel Fortin michel.for...@michelf.com said:
I think we need a third option.
Here's an idea: we could allow modules having a single symbol with the
same name as the module to behave as if they were the symbol itself,
just like templates behaves. For instance:
On Fri, 30 Mar 2012 16:46:19 +0200, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Starting a new thread from one in announce:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
Please comment, after which Walter will approve. Walter's approval means
that he would
On Fri, 30 Mar 2012 17:45:36 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2012-03-30 14:46:19 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
Destroy!
Since you're asking…
One thing the current system avoids is unresolvable symbols. If two
symbol name
On Sat, 31 Mar 2012 00:23:32 -0400, Chris NS ibisbase...@gmail.com wrote:
I'm pretty impressed with the idea, and look forward to its
implementation, but I do have one question. How does this affect (if at
all) the implicit friend relationship of declarations? Since package
foo.bar is
On 2012-04-02 13:04:31 +, Steven Schveighoffer
schvei...@yahoo.com said:
On Fri, 30 Mar 2012 17:45:36 -0400, Michel Fortin
The problem is that if .std.algorithm.package
contains a sort function and there is also a module called
std.algorithm.sort, the fully-qualified name of that 'sort'
Chris NS ibisbase...@gmail.com wrote in message
news:ugopmohijjcnnrchu...@forum.dlang.org...
I'm pretty impressed with the idea, and look forward to its
implementation, but I do have one question. How does this affect (if at
all) the implicit friend relationship of declarations? Since
On Saturday, 31 March 2012 at 06:39:07 UTC, Nick Sabalausky wrote:
Chris NS ibisbase...@gmail.com wrote in message
news:ugopmohijjcnnrchu...@forum.dlang.org...
I'm pretty impressed with the idea, and look forward to its
implementation, but I do have one question. How does this
affect (if at
On Sat, 31 Mar 2012 01:46:19 +1100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Starting a new thread from one in announce:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
Please comment ...
We solved this issue in the Euphoria Programming language by introducing
On 03/30/2012 11:35 PM, Jonathan M Davis wrote:
But personally, I like the idea of making it so that publicly imported symbols
can be accessed as if they were in the module that publicly imported them
+1. That is even better than treating the package module specially.
On Friday, 30 March 2012 at 14:46:16 UTC, Andrei Alexandrescu
wrote:
Starting a new thread from one in announce:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
Please comment, after which Walter will approve. Walter's
approval means that he would approve a pull request
On Sat, 31 Mar 2012 13:06:36 +0200, Timon Gehr timon.g...@gmx.ch wrote:
On 03/30/2012 11:35 PM, Jonathan M Davis wrote:
But personally, I like the idea of making it so that publicly imported
symbols
can be accessed as if they were in the module that publicly imported
them
+1. That is even
Le 30/03/2012 21:33, Andrei Alexandrescu a écrit :
On 3/30/12 1:39 PM, Jonathan M Davis wrote:
However, I'm very nervous about the second part. e.g. std.sort instead of
std.algorithm.sort seems like a bad idea to me. It increases the odds
of name
conflicts for little benefit.
Example?
Not
Le 30/03/2012 23:35, Jonathan M Davis a écrit :
On Friday, March 30, 2012 14:33:58 Andrei Alexandrescu wrote:
On 3/30/12 1:39 PM, Jonathan M Davis wrote:
However, I'm very nervous about the second part. e.g. std.sort instead of
std.algorithm.sort seems like a bad idea to me. It increases the
On 03/31/2012 03:49 PM, Martin Nowak wrote:
On Sat, 31 Mar 2012 13:06:36 +0200, Timon Gehr timon.g...@gmx.ch wrote:
On 03/30/2012 11:35 PM, Jonathan M Davis wrote:
But personally, I like the idea of making it so that publicly
imported symbols
can be accessed as if they were in the module that
However, I'm very nervous about the second part. e.g. std.sort instead of
std.algorithm.sort seems like a bad idea to me. It increases the odds of
name
conflicts for little benefit. Not to mention, it'll make it a lot more
confusing
to find what modules stuff is actually in if people start
Le 30/03/2012 16:46, Andrei Alexandrescu a écrit :
Starting a new thread from one in announce:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
Please comment, after which Walter will approve. Walter's approval means
that he would approve a pull request implementing DIP16 (subject
On Saturday, March 31, 2012 17:30:36 Timon Gehr wrote:
On 03/31/2012 03:49 PM, Martin Nowak wrote:
On Sat, 31 Mar 2012 13:06:36 +0200, Timon Gehr timon.g...@gmx.ch wrote:
On 03/30/2012 11:35 PM, Jonathan M Davis wrote:
But personally, I like the idea of making it so that publicly
imported
Le 30/03/2012 16:46, Andrei Alexandrescu a écrit :
Starting a new thread from one in announce:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
Please comment, after which Walter will approve. Walter's approval means
that he would approve a pull request implementing DIP16 (subject
On 03/30/2012 04:46 PM, Andrei Alexandrescu wrote:
Starting a new thread from one in announce:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
Please comment, after which Walter will approve. Walter's approval means
that he would approve a pull request implementing DIP16 (subject
On second thought, issue 2 is probably not that much of a problem.
On 30/03/2012 15:46, Andrei Alexandrescu wrote:
Starting a new thread from one in announce:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
Please comment, after which Walter will approve. Walter's approval means
that he would approve a pull request implementing DIP16 (subject to
On Fri, 30 Mar 2012 10:46:19 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Starting a new thread from one in announce:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
Please comment, after which Walter will approve. Walter's approval means
that he would
On 3/30/12, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
Destroy!
That means a program that imports std.algorithm may use std.sort
for the symbol std.algorithm.sort.
That's quite interesting. Would that also mean that you could do:
import std.algorithm; // has indexOf
import
On Fri, Mar 30, 2012 at 12:06 PM, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
On 3/30/12, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
Destroy!
That means a program that imports std.algorithm may use std.sort
for the symbol std.algorithm.sort.
That's quite interesting.
On 3/30/12, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
Btw, I bet with the help of hackers like e.g. Kenji Hara we'll have
this implemented in a matter of days (if it gets accepted). Compare
that to having a C++ committee
On Friday, March 30, 2012 09:46:19 Andrei Alexandrescu wrote:
Starting a new thread from one in announce:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
Please comment, after which Walter will approve. Walter's approval means
that he would approve a pull request implementing
On Friday, March 30, 2012 20:06:57 Andrej Mitrovic wrote:
On 3/30/12, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
Destroy!
That means a program that imports std.algorithm may use std.sort
for the symbol std.algorithm.sort.
That's quite interesting. Would that also mean that
On Friday, March 30, 2012 12:15:44 Brad Anderson wrote:
On Fri, Mar 30, 2012 at 12:06 PM, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
On 3/30/12, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
Destroy!
That means a program that imports std.algorithm may use std.sort
On Friday, 30 March 2012 at 18:39:44 UTC, Jonathan M Davis wrote:
I'd propose that we make it so that if a module publicly
imports another
module, then you could treat it as if it were in that module.
So, because
std.datetime.package publicly imports std.datetime.systime, you
could use
On 3/30/12 1:39 PM, Jonathan M Davis wrote:
However, I'm very nervous about the second part. e.g. std.sort instead of
std.algorithm.sort seems like a bad idea to me. It increases the odds of name
conflicts for little benefit.
Example?
Not to mention, it'll make it a lot more confusing
to
My comments:
1. My first impression was that using foo/bar/package.d instead of
foo/bar.d seemed a bit odd and messy. But I realize now that cleverly
solves the issue where foo/bar.d would be considered to be inside a
different package from foo/bar/*.d. So I like that. Personally, I think I
On Friday, 30 March 2012 at 18:15:57 UTC, Brad Anderson wrote:
On Fri, Mar 30, 2012 at 12:06 PM, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
On 3/30/12, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Destroy!
That means a program that imports std.algorithm may use
std.sort
Timon Gehr timon.g...@gmx.ch wrote in message
news:jl4jmg$2j1r$1...@digitalmars.com...
I don't really like the second one.
1. It is an over-general solution, because it does not solve a general
problem.
Maybe it would be better to just interpret foo.bar.baz as
foo.bar.package.baz if
Robert Clipsham rob...@octarineparrot.com wrote in message
news:jl4l5t$2m62$1...@digitalmars.com...
On 30/03/2012 15:46, Andrei Alexandrescu wrote:
Starting a new thread from one in announce:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
Please comment, after which Walter will
On Friday, March 30, 2012 14:33:58 Andrei Alexandrescu wrote:
On 3/30/12 1:39 PM, Jonathan M Davis wrote:
However, I'm very nervous about the second part. e.g. std.sort instead of
std.algorithm.sort seems like a bad idea to me. It increases the odds of
name conflicts for little benefit.
Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message
news:mailman.1240.1333130858.4860.digitalmar...@puremagic.com...
Still this is one of the few proposals I like. My only caveat is the
comment: except the file is not allowed to use the module
declaration.. Wouldn't it be better if we
On Fri, Mar 30, 2012 at 05:35:25PM -0400, Jonathan M Davis wrote:
[...]
But personally, I like the idea of making it so that publicly imported
symbols can be accessed as if they were in the module that publicly
imported them (with package.d being treated as if it had the same name
as the
On 2012-03-30 14:46:19 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
Destroy!
Since you're asking…
One thing the current system avoids is unresolvable symbols. If two
symbol name clashes, you just qualify them fully and it'll always be
unambiguous. For instance:
On 3/30/12 10:46 PM, Andrei Alexandrescu wrote:
Starting a new thread from one in announce:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
Please comment, after which Walter will approve. Walter's approval means
that he would approve a pull request implementing DIP16 (subject to
I'm pretty impressed with the idea, and look forward to its
implementation, but I do have one question. How does this affect
(if at all) the implicit friend relationship of declarations?
Since package foo.bar is treated as a single module, do the
classes in foo/bar/alpha.d and foo/bar/beta.d
On Saturday, March 31, 2012 06:23:32 Chris NS wrote:
I'm pretty impressed with the idea, and look forward to its
implementation, but I do have one question. How does this affect
(if at all) the implicit friend relationship of declarations?
Since package foo.bar is treated as a single module,
98 matches
Mail list logo
