On Tuesday, 12 February 2013 at 19:38:56 UTC, qznc wrote:
> 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.


Agreed. It's such an enormous problem, even just in English. You're much better off creating a special tool that satisfies your own needs for the specific set of words that you need pluralisin.

On 2013-02-12 20:38, qznc wrote:
> Do not go down that rabbit hole! Just skim over the following links to get an
> idea how complicated this becomes.

I know that. Usually I define my own pluralize for the one or two languages I use. Good enough solution when you don't need to have your software translated into all possible languages. Last chat we had about i18n and making our own flavor of gettext ended up with the statement that apparently we need keyword arguments in writefln format strings first... so I decided to rest my case. ;)

On 2013-02-12 17:53, Peter Sommerfeld wrote:

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

It's not so much about priority, it's rather about if being accepted at all.

-- 
/Jacob Carlborg

On 2/12/2013 6:53 AM, Steven Schveighoffer wrote:
> Well, many of those could be implemented in Orbit, especially the trivial ones.

The trivial ones should not be added to Phobos, for example, 'any' being defined as '!empty'. Such things add cognitive load but no value.

On 2/12/2013 4:38 AM, Jacob Carlborg wrote:
> * Serialization - Does not exist

The existence of UDAs should dramatically affect the design of a serialization library.

On 2013-02-12 22:35, Walter Bright wrote:

> The trivial ones should not be added to Phobos, for example, 'any' being
> defined as '!empty'. Such things add cognitive load but no value.

This is just an extension to the already existing std.algorithm.any function. I think it adds value, that's why I have it. It clearly shows the intent. It's the same reason why I think it's good to have explicit interfaces and abstract classes in opposite of how it works in C++.

-- 
/Jacob Carlborg

On 2013-02-12 22:40, Walter Bright wrote:

> The existence of UDAs should dramatically affect the design of a
> serialization library.

It didn't dramatically affect my serialization library. I already used a poor man's implementation of UDAs, perhaps that's why.

Without UDA:

class Foo
{
    int a;
    int b;

    mixin NonSerialized!(b);
}

With UDA:


class Foo
{
    int a;
    @nonSerialized int b;
}

The UDAs just add some syntax sugar.

-- 
/Jacob Carlborg

Am Tue, 12 Feb 2013 13:38:53 +0100
schrieb Jacob Carlborg <doob@me.com>:

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

I can only tell you what of that list I would have had a use
for myself in the past:

>    * Configuration

Yes, native to the environment (e.g. use \AppData\Roaming on
Windows or .config on Linux)

> * 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");

I loaded an .INI template at CT (with default values and type inference) and created nested structs from that. Was fun to do in D. No matter what the implementation is, this is useful.

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

The biggest shortcoming is that you cannot do IPC with it, as it doesn't give you two-way pipes to the child process. Again, that's useful and IIRC was in the std.process replacement.

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

All of that except "action" and "multiple command lines".
Validation is probably too complex to include at the spot. I
mean, sometimes you need to validate the combination of all
options, so you can just as well write a separate function.

> CTFE:

I think most of that exists in Phobos or can be constructed in one line of code:

> * format - A simple formatting function

http://dlang.org/phobos/std_metastrings.html#.Format

> * indexOf

http://dlang.org/phobos/std_typetuple.html#.staticIndexOf

> * contains

staticIndexOf!(something, Tuple) != -1

> * fieldsOf - Returns all the fields of the given type

http://dlang.org/phobos/std_traits.html#.FieldTypeTuple

> * hasField - Returns true if the given type has the given field

staticIndexOf!(field, fieldsOf!Type) != -1

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

:( No idea... at least without mixins.

> * newInstance - Returns a new instance based on the class name or ClassInfo. Can handle any class regardless of constructors

So I figure, Object.factory("ClassName") is too limited. I used to just force my code work with that one.

-- 
Marco

On Wednesday, February 13, 2013 09:34:36 Marco Leise wrote:
> > * format - A simple formatting function
> 
> http://dlang.org/phobos/std_metastrings.html#.Format

format now works in CTFE. Format should go the way of the dodo. It's insanely inefficient.

- Jonathan M Davis

On 2013-02-13 09:45, Jonathan M Davis wrote:
> On Wednesday, February 13, 2013 09:34:36 Marco Leise wrote:
>>> * format - A simple formatting function
>>
>> http://dlang.org/phobos/std_metastrings.html#.Format
>
> format now works in CTFE. Format should go the way of the dodo. It's insanely
> inefficient.

Could you please add this info to std.metastrings' ddoc?