DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Timothee Cour via Digitalmars-d]

Andrei: you can use blockquotes to make long lines wrap when quoting text:

https://github.com/adam-p/markdown-here/wiki/Markdown-Here-Cheatsheet#blockquotes

that way, we don't have to scroll everytime there's a quote, eg:

replace:
<tab>Such scaffolding is of course
with:
> Such scaffolding is of course




On Mon, Dec 19, 2016 at 8:04 PM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On 12/19/2016 01:47 AM, Joakim wrote:
>
>> Why do you care _so_ much about the module dependency graph?  To make
>> this question concrete, let's look at an example, the std.array module
>> you keep mentioning.
>> This is what it looked like before Ilya scoped as
>> many imports as he could:
>>
>> https://github.com/dlang/phobos/commit/3fcf723aa498b96de1653
>> 61b5abb9d3450fdc069#diff-54cf8402b22024ae667d4048a5126f0e
>>
>> That was a mess, similar to opaque C/C++ code, 13 modules imported at
>> module-scope were whittled down to 4.  You just made those more specific
>> in a commit related to this DIP, by listing the actual symbols
>> selectively imported from those four modules:
>>
>> https://github.com/dlang/phobos/commit/e064d5664f92c4b2f0866
>> c08f6d0290ba66825ed#diff-54cf8402b22024ae667d4048a5126f0e
>>
>>
>> If I'm looking at the template constraints for any particular function
>> and see a couple symbols I don't recognize, I don't think it's a big
>> deal to find the symbols in that list at the top.
>>
>
> It actually is. Some symbols in e.g. std.range are used in constraints,
> some others used in definitions; some in a UFCS manner. Some code runs
> during compilation, with errors gagged (as in __traits(compiles)) or not
> gagged. I don't know of an easy manual method to figure out who's who
> (which makes Vladimir's idea of tooling it with brute force awesome and
> scary at the same time).
>
> At any way, I don't see how I can use this tidbit to improve the DIP.
> Anything I could add to it to make it more compelling?
>
> In other words, D already allows you to scope most imports.  I don't
>> consider the dozen or two remaining symbols from templaint constraints
>> and function arguments to provide much overhead.  Rather, I consider the
>> weight of this additional syntax, ie the cognitive overhead from having
>> to remember and parse more syntax in my head, to be worse than the
>> remaining dependency reasoning problem you're trying to solve: the cost
>> outweights the benefit.  Perhaps that's subjective and others may
>> disagree.
>>
>
> It is subjective and difficult to convert into action. Online review among
> folks who know next to nothing about each other does have its challenges.
> What happens here is I post a proposal for a problem that I believe is
> important for large D projects. And I get back "eh, that's not as important
> to me." At a traditional work place we'd know a lot about one another's
> strengths, specialization areas, and design sensibilities. Here, all I can
> do is look at your past PRs (that's why I emailed you asking for your
> github handle; I figure it's @joakim-noah). This makes it difficult to act
> on "I don't buy it" feedback.
>
> Now, there's also the question of purely technical benefits, like
>> compilation speed or executable bloat.  I looked at the latter a little
>> last summer, after Ilya had cleaned up a lot of the standard library:
>>
>> http://forum.dlang.org/thread/gmjqfjoemwtvgqrtdsdr@forum.dlang.org
>>
>> I found that commenting out a single scoped, selective import of
>> "std.string: format" in std.utf led to a 5% decrease in executable size
>> for "hello world."  This is a problem with how dmd compiles or appends
>> these module dependencies and would presumably still be there after this
>> DIP, as you would not remove the dependency.
>>
>
> That might be a related but distinct issue. Can you reproduce that
> experiment?
>
> I think scoped, selective imports have been great at hacking away at the
>> module dependency graph, as you lay out.  It is not clear what technical
>> costs you see from the remaining few dependencies and if this DIP is the
>> best way to remove them.  I think you should explain why you want to
>> untangle the remaining dependency graph, and consider if this DIP is
>> really doing that much.
>>
>
> I've made a few more passes through the DIP, but throughout I assume a
> couple of things without stressing them too much - dependencies are
> important, and associating dependencies with declarations makes the
> dependency graph as fine and as precise it could get. I don't see a
> reasonable way to make it better or clearer.
>
> Should I add an introductory section on why dependencies are important?
>
>
> Andrei
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20161219/22eb4eeb/attachment.html>