DIP11: Automatic downloading of libraries

[Jonathan M Davis]

On 2011-06-21 14:27, Byakkun wrote:
> On Tue, 21 Jun 2011 21:01:07 +0300, Jacob Carlborg <doob at me.com> wrote:
> > On 2011-06-21 19:36, Jonathan M Davis wrote:
> >> On 2011-06-21 10:17, Jacob Carlborg wrote:
> >>> Maybe I was a bit too harsh saying that std.benchmark maybe wasn't
> >>> worth
> >>> adding. On the other hand isn't this what the review process is about
> >>> (or maybe this is before the review process)? We can't include
> >>> EVERYTHING in Phobos or it will become like the Java/C# standard
> >>> library, I assume we don't want that.
> >> 
> >> Why not? Granted, we want quality code, and we only have so many people
> >> working on Phobos and only so many people to help vet code, but
> >> assuming that
> >> it can be written at the appropriate level of quality and that the
> >> functionality is generally useful, I don't see why we wouldn't want a
> >> large
> >> standard library like Java and C# have. Given our level of manpower, I
> >> don't
> >> expect that we'll ever have a standard library that large, but I don't
> >> see why
> >> having a large standard library would be a bad thing as long as it's of
> >> high
> >> quality and its functionality is generally useful.
> >> 
> >> - Jonathan M Davis
> > 
> > I just got that impression. That we want a relative small standard
> > library and have other libraries available as well.
> 
> I see only one perspective from which you would like to not have
> standard libs as large as C# an Java provided the quality of the code is
> good and that is the fact that you can't realistically hope to have the
> IDEs they have which integrate facilities to access the documentation very
> easily or one can just to rely on auto-completion (which also gives Java
> and C# the luxury to use very very explicit and strait forward naming).
> This is worthy of consideration for phobos (the fact
> that it doesn't come bundled with an IDE like C#). Otherwise it is good
> to have as much std as possible and useful. My only concern (excepting
> bugs and holes in Phobos) is that the packages are not grouped at all
> and that increases the time (at least for a noob) it take to search
> through the documentation and the code. Also there is some ambiguity to
> regarding the place of some functionality like std.array and std.string
> (I fond myself surprised in other areas but I can't remember right now)
> which I imagine it could be fixed simply by intelligently using D module
> system. But maybe there are reasons for doing it this way which I don't
> get.

As far as std.array vs std.string goes, functionality which generalizes to 
arrays is supposed to be in std.array, whereas functionality which only makes 
sense for strings belongs in std.string. For instance, toUpper makes sense in 
std.string but not in std.array, since it only makes sense to uppercase 
strings, not general characters, whereas a function like replicate makes sense 
for arrays in general, so it's in std.array. Where it's likely to be 
surprising is with functions like split where you would initially think that 
it applies only to strings, but it has an overload which is more generally 
applicable, so it's in std.array. And several functions were moved to 
std.array from std.string a couple of releases back, so if you were used to 
having them in std.string, it could throw you off. There are probably a few 
places where functions might be better moved to another module, and there are 
definitely cases where it's debatable whether they belong in one module or 
another, but overall things are fairly well organized. In some cases, we may 
eventually have to move to a deeper hierarchy, but with what we have at the 
moment, I don't think a deeper hierarchy would help us much. It's not like 
Java where everything is a class and every class is in its own module. In that 
kind of environment, you pretty much have to have a deep hierarchy. But that's 
not the case with D.

- Jonathan M Davis