On 6/23/15 10:15 AM, Adam D. Ruppe wrote:
On Tuesday, 23 June 2015 at 16:56:55 UTC, Andrei Alexandrescu wrote:
But that doesn't apply to packages that do NOT originate as big
modules, so they have no backward compatibility issue.
My thought isn't really about backward compatibility but about
minimizing dependencies with sibling modules.
I don't want to repeat my argument too much from the other thread, but
imagine you're writing a minimalist library that is meant to interact
with other minimalist libraries. To interact, you want a shared
interface and basic types. But to be minimalist, you want to pull as
little other standard code as possible.
The typical user might just import std.whatever and get it all
available. But this minimalist user only wants
std.whatever.basic_interface. If the basic interface is shoved inside
package.d, she can't get get to it without inadvertently pulling in more
modules too. This can quickly grow into a web of dependencies where
importing just an interface definition ends up grabbing dozens if
implementations you don't want too, bloating compile times and binary
sizes.
The case with std.allocator is not everything is imported in it, so no
bloating no nothing. -- Andrei
