In the thread "Expanding Phobos from a flat hierarchy" there started a discussion about package managers. Of course I mentioned the package manager I'm working on, Orbit. Unfortunately people weren't very happy with the third party dependencies. So I compiled a list of what's missing from Phobos, but I never got an answer to that post in the thread. I have now repeated the list below of what Orbit needs that don't exist in Phobos. I hope I have better luck here.

Repeated message:

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.

Original message: http://forum.dlang.org/thread/ugmacrokqghrrwpfovam@forum.dlang.org?page=6#post-kf15td:24v63:241:40digitalmars.com

-- 
/Jacob Carlborg

Some answers:

On Tue, 12 Feb 2013 07:38:53 -0500, Jacob Carlborg <doob@me.com> wrote:

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

I want to get this remedied.  Won't make it in 2.062, but I want to finish this in the next month.

> * 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

I know std.getopt doesn't support all these, but couldn't you support them externally?  I mean, let getopt assign the values, then perform the logic based on what you got?  You have to write the logic anyway.  I suppose one of the missing pieces here is whether an option was present or not.  All you get is the result.

You can handle the command before handling the options, as long as you require the command to be the first parameter.

> Various convince functions:
>
> * any - Opposite of empty

!empty

> * last - Returns the last element of an array

arr[$-1];
arr.back;

> * map, find and any for associative arrays

Really, we need an AA range...

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

basic version:
string pluralize(string x, int count)
{
   return count > 1 ? x ~ "s" : x;
}

Now, you probably would need a simple mechanism to do the different plural forms.  Sometimes 'es' must be added, sometimes 'y' must be changed to 'ies', etc.  But that should be a simple switch statement.  The switch statement would select a different ending, and a prefix count based on the current ending.

Then the return would be:

return count > 1 ? x[0..pcount] ~ ending : x;

-Steve

On 2013-02-12 15:21, Steven Schveighoffer wrote:
> Some answers:
>
> On Tue, 12 Feb 2013 07:38:53 -0500, Jacob Carlborg <doob@me.com> wrote:
>
>> * std.process - I have not used it myself but I've heard it's not optimal
>
> I want to get this remedied.  Won't make it in 2.062, but I want to
> finish this in the next month.
>
>> * 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
>
> I know std.getopt doesn't support all these, but couldn't you support
> them externally?  I mean, let getopt assign the values, then perform the
> logic based on what you got?  You have to write the logic anyway.  I
> suppose one of the missing pieces here is whether an option was present
> or not.  All you get is the result.
>
> You can handle the command before handling the options, as long as you
> require the command to be the first parameter.
>
>> Various convince functions:
>>
>> * any - Opposite of empty
>
> !empty
>
>> * last - Returns the last element of an array
>
> arr[$-1];
> arr.back;
>
>> * map, find and any for associative arrays
>
> Really, we need an AA range...
>
>> * pluralize - Takes a string and a count. If the count is greater than
>> 1 it converts the word in the string to plural
>
> basic version:
> string pluralize(string x, int count)
> {
>     return count > 1 ? x ~ "s" : x;
> }
>
> Now, you probably would need a simple mechanism to do the different
> plural forms.  Sometimes 'es' must be added, sometimes 'y' must be
> changed to 'ies', etc.  But that should be a simple switch statement.
> The switch statement would select a different ending, and a prefix count
> based on the current ending.
>
> Then the return would be:
>
> return count > 1 ? x[0..pcount] ~ ending : x;

I don't need examples of how to implement these functions. I'm asking what of these could we add to Phobos. I already have all the functionality in place. I'm trying to estimate the cost of moving these to Phobos, if it's worth porting Orbit to only use Phobos.

-- 
/Jacob Carlborg

On Tue, 12 Feb 2013 09:38:45 -0500, Jacob Carlborg <doob@me.com> wrote:

> I don't need examples of how to implement these functions. I'm asking what of these could we add to Phobos. I already have all the functionality in place. I'm trying to estimate the cost of moving these to Phobos, if it's worth porting Orbit to only use Phobos.
>

Well, many of those could be implemented in Orbit, especially the trivial ones.

The way it was worded, I thought you needed those to be in phobos or have an implementation provided before you could start the port.  It did sound a little strange ;)

Some of them are not trivial, and I understand those (e.g. std.process and std.xml), but things like !empty I think would not need a special implementation in phobos for you to be able to port.

-Steve

On 2013-02-12 15:53, Steven Schveighoffer wrote:

> Well, many of those could be implemented in Orbit, especially the
> trivial ones.
>
> The way it was worded, I thought you needed those to be in phobos or
> have an implementation provided before you could start the port.  It did
> sound a little strange ;)

I would prefer if they were in Phobos, since they are generic and can be used by any application.

> Some of them are not trivial, and I understand those (e.g. std.process
> and std.xml), but things like !empty I think would not need a special
> implementation in phobos for you to be able to port.

I moved this functionality out of Orbit into one of my own libraries because it's generic and can be used by any application.

-- 
/Jacob Carlborg

On 2013-02-12 15:53, Steven Schveighoffer wrote:

> Well, many of those could be implemented in Orbit, especially the
> trivial ones.
>
> The way it was worded, I thought you needed those to be in phobos or
> have an implementation provided before you could start the port.  It did
> sound a little strange ;)
>
> Some of them are not trivial, and I understand those (e.g. std.process
> and std.xml), but things like !empty I think would not need a special
> implementation in phobos for you to be able to port.

The original problem was Orbit is using third party libraries which is not acceptable if Orbit is to be included in the official distribution. This is according to Andrei and Jonathan.

The question then is: Which of the needed functionality can be moved to Phobos and which can not be?

I would like to avoid rewriting large parts of the code that is already working perfectly fine.

I also don't think it's good to include large part of library code in Orbit, i.e. a serialization library.

-- 
/Jacob Carlborg

On 2013-02-12 15:21, Steven Schveighoffer wrote:
> string pluralize(string x, int count)
> {
>     return count > 1 ? x ~ "s" : x;
> }

You mean: return count != 1 ? x ~ "s" : x;
For special cases there could be a third optional argument:

    string pluralize(int count, string sng, string pl="") {
        return count == 1 ? sng : pl.length ? pl : sng ~ "s";
    }
    writeln(pluralize(2, "cat"));
    writeln(pluralize(2, "radius", "radii"));


That's for simple English-only pluralization, before we jump into translations.

Jacob Carlborg wrote:
> The question then is: Which of the needed functionality can be moved to Phobos and which can not be?
>  I would like to avoid rewriting large parts of the code that is already working perfectly fine.
>  I also don't think it's good to include large part of library code in Orbit, i.e. a serialization library.

That seems to be a question of priority: If you insist to get the
dependencies into phobos first it will take some time until that
happens, may be never or parts of it only.

A solution for now seems to be to pack the dependencies into Orbit
and later push parts of it into phobos. That will establish an API
which defines the d-package manager, provided it is accepted by
Walter and Andre. Your decision...

Peter

On Tuesday, February 12, 2013 09:21:08 Steven Schveighoffer wrote:
> > * pluralize - Takes a string and a count. If the count is greater than 1 it converts the word in the string to plural
> 
> basic version:
> string pluralize(string x, int count)
> {
> return count > 1 ? x ~ "s" : x;
> }
> 
> Now, you probably would need a simple mechanism to do the different plural forms. Sometimes 'es' must be added, sometimes 'y' must be changed to 'ies', etc. But that should be a simple switch statement. The switch statement would select a different ending, and a prefix count based on the current ending.

Actually, given that that's English-specific, I don't know that we'd actually want that. I think that we do have a few English-specific items in Phobos, but for the most part, that really belongs in internationalization of some variety. But maybe it would be okay to add. If not, given how simple it is, if Orbit really needs it, I wouldn't think that it would be a big deal for it to just include it internally.

- Jonathan M Davis

On Tuesday, 12 February 2013 at 16:38:54 UTC, FG wrote:
> On 2013-02-12 15:21, Steven Schveighoffer wrote:
>> string pluralize(string x, int count)
>> {
>>    return count > 1 ? x ~ "s" : x;
>> }
>
> You mean: return count != 1 ? x ~ "s" : x;
> For special cases there could be a third optional argument:
>
>     string pluralize(int count, string sng, string pl="") {
>         return count == 1 ? sng : pl.length ? pl : sng ~ "s";
>     }
>     writeln(pluralize(2, "cat"));
>     writeln(pluralize(2, "radius", "radii"));
>
>
> That's for simple English-only pluralization, before we jump into translations.

Do not go down that rabbit hole! Just skim over the following links to get an idea how complicated this becomes.

https://developer.mozilla.org/en/docs/Localization_and_Plurals
http://doc.qt.digia.com/qq/qq19-plurals.html

I am not sure, if any internationalization stuff should be in std. No matter how you do it, it will be too simple for some and too over-engineered for others.

There will always be multiple solutions on different levels of power and applications have to choose, which suits them best.

My advice: If you find your self wanting that, try to rephrase first.

For example, instead of "there are %d cat(s)" output "number of cats: %d". It will be much easier to internationalize.