Recently I've struggled again to integrate a module in Phobos and the
amount of curious forward reference bugs made think about a related but
not equivalent problem.
Intro
Basically an import graph of Phobos is a rat's nest of mutual imports.
With the most of modules being template "toolkits"
On Wednesday, 24 April 2013 at 12:03:52 UTC, Dmitry Olshansky
wrote:
E.g. std.regex would import std.concept.random to get
isUniformRNG and rely on duck typing thusly described to use it
correctly.
Thoughts? Other ideas?
how would this be different then limited imports such as:
import std.ran
On Wednesday, 24 April 2013 at 12:03:52 UTC, Dmitry Olshansky
wrote:
Basically an import graph of Phobos is a rat's nest of mutual
imports.
With the most of modules being template "toolkits" you
shouldn't pay for what you don't use. Yet it isn't true in
general as the module may drag in other m
Am Wed, 24 Apr 2013 16:03:47 +0400
schrieb Dmitry Olshansky :
> Thoughts? Other ideas?
>
Sounds good to me. We might extend this idea and also add interfaces to
the concept modules. Tango did that and IIRC C# does this as well.
24-Apr-2013 19:56, Joshua Niehus пишет:
On Wednesday, 24 April 2013 at 12:03:52 UTC, Dmitry Olshansky wrote:
E.g. std.regex would import std.concept.random to get isUniformRNG and
rely on duck typing thusly described to use it correctly.
Thoughts? Other ideas?
how would this be different then
24-Apr-2013 20:08, qznc пишет:
On Wednesday, 24 April 2013 at 12:03:52 UTC, Dmitry Olshansky wrote:
Basically an import graph of Phobos is a rat's nest of mutual imports.
With the most of modules being template "toolkits" you shouldn't pay
for what you don't use. Yet it isn't true in general as
On Wednesday, 24 April 2013 at 19:33:51 UTC, Dmitry Olshansky
wrote:
24-Apr-2013 20:08, qznc пишет:
What are you actually worried about? Compile times? Program
size?
Startup time?
It affects all of it.
I don't know if you are right, but I think the case would be made
visible and compelling
On Wednesday, April 24, 2013 16:03:47 Dmitry Olshansky wrote:
> What we need is to re-arrange the module hierarchy (and we need that
> anyway) so that we split off the "concept" part of modules to a separate
> package.
> Thoughts? Other ideas?
I'm a bit divided on the idea. On the one hand, it al
26-Apr-2013 03:20, Zach the Mystic пишет:
On Wednesday, 24 April 2013 at 19:33:51 UTC, Dmitry Olshansky wrote:
24-Apr-2013 20:08, qznc пишет:
What are you actually worried about? Compile times? Program size?
Startup time?
It affects all of it.
I don't know if you are right, but I think the
26-Apr-2013 07:23, Jonathan M Davis пишет:
On Wednesday, April 24, 2013 16:03:47 Dmitry Olshansky wrote:
What we need is to re-arrange the module hierarchy (and we need that
anyway) so that we split off the "concept" part of modules to a separate
package.
Thoughts? Other ideas?
I'm a bit di
On Saturday, April 27, 2013 00:26:05 Dmitry Olshansky wrote:
> Thinking more of it - the idea would have been neat and elegant with a
> variation on DIP 15. Then std.xyz.trait would be the trait part of a
> package.
>
> http://wiki.dlang.org/DIP15
We really do need a variant of DIP 15 or 16. I ac
27-Apr-2013 00:26, Dmitry Olshansky пишет:
Have you read the description? I gave the exact cases where regardless
of templates or no templates you do pull in the module. This is a
problem that defeat the whole goodness of generating only the code you
use (via templates). In fact I'll post about m
On Wednesday, 24 April 2013 at 12:03:52 UTC, Dmitry Olshansky
wrote:
Recently I've struggled again to integrate a module in Phobos
and the amount of curious forward reference bugs made think
about a related but not equivalent problem.
Intro
Basically an import graph of Phobos is a rat's nest
13 matches
Mail list logo
