phobos alt.

Jonathan M Davis jmdavisProg at gmx.com
Sat Oct 29 18:04:18 PDT 2011


On Saturday, October 29, 2011 17:49:40 bls wrote:
> On 10/29/2011 05:26 PM, Jonathan M Davis wrote:
> > f you want to have or use a 3rd party library, that's fine. But there's
> > no reason to put such a library inside of the standard library. That's
> > just confusing to people. std.container is how Phobos is going to do
> > containers. It needs to be fleshed out, and it's possible that its API
> > needs some refinement, but sticking alternate implementations of things
> > inside of the standard library is just confusing and schizophrenic. The
> > standard library will have what it will have and implement that how it
> > implements it. It's
> > counterproductive to put a bunch of different ways to do the same thing
> > in the standard library. If someone wants a different design or
> > implementation, they can create or use 3rd party library which does
> > that. There's no need for it to be officially sanctioned in the
> > standard library. So, if someone wants to use dcollections, then let
> > them use dcollections, but that's no reason to stick it in Phobos which
> > already has a different design for how its containers work.
> Hi Jonathan,
> I think I get your point. And sure there are pros and cons Since I am
> convinced that there are more pros (otherwise I would simply shut up)
> Let me try to argue for my position.
> 
> let's start with std.xml I guess you will agree that std.xml is ahem..
> not perfect. Now there is something better, on dsource, google, git,
> Dunno.  Isn't better to have such an alt.xml lib handy..without searching ?
> 
> Let's take collections, Here we have atm nothing comparable in phobos.
> Let me ask : Having dcollections in phobos ..Will it break some
> _existing_ code ?
> 
> Not my last argument.. but heck I am tiered. Simple, but important
> libraries are hanging around, {somewhere}, a guid lib, a crypt lib, a
> financial math lib. etc. why not having *alt.* as say.. incubator.

std.xml is going to be replaced. We don't want to leave bad code in Phobos. If 
something really needs to be replaced, then we're going to replace it, not 
just create a separate module which does the same thing but differently. We 
don't need a separate container library in Phobos. We _do_ need a container 
library, and the one that we have is woefully inadequate, but there are 
already plans to expand it appropriately. There's no need to add a second 
container library.

It has already been suggested in the past that we have an incubator project of 
sorts, and there's a lot to be said for that, but we don't need that to be in 
the standard library. It should be a completely separate project IMHO. The 
only thing stopping it from happening is that no one has created it. Someone 
needs to champion such a project, and that hasn't happened - probably because 
it would be a fair bit of work.

- Jonathan M Davis


More information about the Digitalmars-d mailing list