Expanding Phobos from a flat hierachy

[Jacob Carlborg]

On 2013-02-06 23:00, Andrei Alexandrescu wrote:

I'll start with some top posting and summarize. I use what works. If 
that means using some third party library I have no problem with that. 
Why should I reimplement something and hope for inclusion into Phobos 
when there already exist a perfectly good and working implementation.

> I think one demotivating factor for both Jacob and the loosely-defined
> core D team is that we quickly reach irreducible positions on
> fundamental matter. It took literally two years for Jacob to decide to
> do away with Ruby. (Two years for real:
> https://github.com/jacob-carlborg/orbit/issues/1)

I don't understand the hate about Ruby. People have just suggested to 
use JSON in this thread. Ruby can use the same syntax:

foo = {
   a: 3,
   b: 4
}

Now we have
> dependencies on https://github.com/jacob-carlborg/dstack and
> https://github.com/jacob-carlborg/mambo. I took a look. This codebase is
> entirely neat and I'm glad a combination of author's talent and D makes
> the code so easy on the eyes, but there's no way we can ever make this
> part of the official distribution. It's parallel to the canon and some
> of it dedicates hundreds of lines to duplicating Phobos functionality
> with minor distinctions in functionality.

Some of these modules go back to 2007, back when I was using D1. Some 
are just different names for functions in Phobos which I understand what 
you're not thrilled about including. Some are/were missing functions 
that I included in my own library instead of contributing to Phobos. I 
don't have time to wait five months for hoping something is included 
into Phobos.

> I'm looking at e.g.
> https://github.com/jacob-carlborg/mambo/blob/master/mambo/arguments/Arguments.d
> which I bet money does some cool things with command-line arguments, but
> I see no reason for using it over std.getopt.

This is a wrapper around the arguments parser in Tango which and some 
syntax sugar. It also helps integrating Formatter, mentioned below.

Similarly
> https://github.com/jacob-carlborg/mambo/blob/master/mambo/arguments/Formatter.d
> is yet another std.format. Then,
> https://github.com/jacob-carlborg/mambo/blob/master/mambo/core/Array.d
> seems to be in the midst of a retrofitting to use std.algorithm as much
> of what it does now is do algorithm-y work with slightly changed names.

Since you wrote that comment I assume you haven't even looked at it, 
just the name. This module is specifically designed to automatically 
generate a usage/help text from the Arguments module above. I can see no 
such functionality in std.format, am I wrong?

> Again, this is all fine and I'm not criticizing. If the purpose is to
> build a package manager for one's own use and to amass a community of
> users around it, great. But if the purpose is to make Orbit _the_
> official package manager of the D programming language, there's no
> equivalent but distinct libraries for command-line arguments, no
> beginsWith that does what startsWith does, etc. etc. etc.

Yes, this contains new names for functions already available in 
std.algorithm. It also contains some tweaks here and there, convenient 
functions and new functionality that is missing from Phobos.

> There are three ways I see out of this: (a) Jacob goes full bore and
> ports Orbit to Phobos, and proposes the generally useful parts of his
> library for inclusion in Phobos; (b) Jacob agrees for someone else to do
> a clean room implementation of his package manager design; (c) we agree
> with the status quo with the understanding there's no more dangling of
> Orbit as a possible official package manager.

Doing some renames and similar is one thing but I have no intention of 
reimplementing a lot of code that is working perfectly fine and hoping 
for a inclusion into Phobos that most likely won't happen.

I've tried to get a review of my serialization library for several 
years, sure it was a form or pre-review with the promise of removing any 
Tango and D1 related code if it was accepted. Nobody was interested. 
Sure I got the usual comments, I got real feedback from a single person 
here, but no formal review. Thank god I didn't remove the Tango and D1 
stuff, that would be been a lot of unnecessary work and wasted time. I 
tried to get a review several times, but I've lost interested now, since 
no one else was interested.

I'm also using a high level testing framework called Cucumber (uses 
Ruby). I'm 99% sure that you have no interest in this. It's a perfect 
framework to do this kind of testing I'm using it for. It's already 
available, working good and are supported by editors. Running tests, 
syntax highlighting and so on. Why should I give up that?

I'm also not a fan of putting unit tests inline. I prefer to have a 
completely separate directory structure for my tests. My unit tests also 
uses a simple unit testing library that allows to continue after a 
assertion failure and gives summary at the end if any tests failed. I'm 
pretty sure you don't want this either. It's already there, it's working 
fine. Why should I give up that?

I've compiled a list below of things used in Orbit (directly or 
indirectly) that Phobos is lacking in. Please tell me if I'm wrong:

* DStack - Is a library for helping structuring applications. It includes:
   * Handling of command line arguments
   * Components
   * Commands
   * Starting and initializing of the application
   * Configuration
I plan to add more stuff here when needed

* Serialization - Does not exist
* ConfigMap -  Does not exist. An associative array with opDispatch 
added to it. Allows to do things like:

auto config = ConfigMap();
config.foo = "asd";
config.bar.foo.baz = "foobar";

assert(config.foo == "asd");

* XML - The XML module is slow and has a cumbersome API

* Zip - I don't exactly remember what was wrong here. It either didn't 
work or I had to reimplement a lot of functionality already available in 
Tango.

* Net - std.curl is probably a good module but it wasn't available when 
I started. I also adds another dependency.

* std.process - I have not used it myself but I've heard it's not optimal

* std.getopt - Doesn't support the following:
   * Required arguments
   * Restricting the values of a given argument
   * No way to automatically create a help/usage list out of the arguments
   * Handling positional arguments
   * No support for commands/action. That is "git commit", "commit" 
would be the command/action
   * Handle multiple command lines
   * Validation of the arguments

Various convince functions:

* any - Opposite of empty
* last - Returns the last element of an array
* map, find and any for associative arrays
* Utility functions for handling UDA's

* isBlank - Check if a value if blank. If it's a string it's blank if 
it's only contains whitespace. If it you can call .empty return that. If 
it's a value type it's not empty. If it's a reference type and it's null 
it's empty

* isPresent - The opposite of isBlank

* pluralize - Takes a string and a count. If the count is greater than 1 
it converts the word in the string to plural

CTFE:

* format - A simple formatting function
* indexOf
* contains
* hasField - Returns true if the given type has the given field
* fieldsOf - Returns all the fields of the given type
* TypeOfField - Returns the type of a field
* nameOfFieldAt - Returns the name of the field at the given position
* set/getValueOfField - Sets/gets the value of a field
* newInstance - Returns a new instance based on the class name or 
ClassInfo. Can handle any class regardless of constructors

* A couple of traits

In the end it's all about what's working.

-- 
/Jacob Carlborg