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

Reply via email to