Experimental Phobos modules?

Jonathan M Davis jmdavisProg at gmx.com
Wed Dec 5 00:42:54 PST 2012


On Wednesday, December 05, 2012 09:27:39 Alex Rønne Petersen wrote:
> Hi,
> 
> I think we need a semi-formal process for experimental Phobos modules.
> That is, modules that are slated for the Phobos review process and/or
> eventual inclusion in Phobos but needs actual field testing to work out
> a proper interface or implementation.
> 
> (I'm assuming most people in the community think an experimental package
> namespace in Phobos is a good idea.)
> 
> Some people see the "etc" package as being this but I think it's too
> poorly named. Something like "experimental" (or just "exp") would be
> more sensible IMO.
> 
> Does anyone have any thoughts on how we might do this? Any bikeshedding?
> I'm not really sure what the best way to go about this is, so really,
> any input is very welcome.

Given the discussions of stability of late, I _have_ wondered if we would be 
better off if instead of directly merging new modules into Phobos, we put them 
in a package (e.g. experimental) which was known to be temporary so that 
people could mess around with it before its API was more or less set in stone. 
Only after some time in there would they actually move into Phobos proper. The 
review process helps a great deal, but the modules don't always get much use 
before they're actually merged in, and actual use can definitely reveal flaws 
that even a solid review won't.

Whether we want some kind of experimental set of modules in Phobos which 
_could_ be reviewed, I don't know. I'm inclined to think that that's a bad 
idea. However, it might be a good idea if we had a separate project (akin to 
Boost perhaps) with a lower standard for inclusion and minimal long term 
stability so that more modules could be tested and tried out before going 
through the actual review process. It would also potentially make it easier 
for programmers to take other people's code and make it Phobos ready when the 
original programmers are willing to write it in the first place but not got the 
extra mile to make it Phobos ready, as they could put into that incubator 
project to be used, abused, and improved by others.

Regardless, I think that we need to look at finding ways to make sure that 
major inclusions to Phobos get more actual field testing before being put into 
Phobos in their final form. The review process is great, but I don't think that 
it's always enough to make sure that a module's API is really going to work 
long term. And if we want long term stability, we need to make sure that new 
modules are really ready to have their APIs essentially frozen when they make 
it into Phobos proper (allowing further additions but avoiding breaking 
compatibility with any changes that are made).

- Jonathan M Davis


More information about the Digitalmars-d mailing list