On 2013-02-14 13:42, Andrei Alexandrescu wrote:

> I understand. Adding functions such as the negation of empty becomes a
> judgment call.
>
> Phobos does have quite a few simple functions that could be easily
> achieved through expression composition (e.g. trim) or statement
> composition (e.g. enforce). So again it's all a matter of judgment.
>
> Walter and I don't consider the negation of empty as useful enough to
> receive a name.

How about this, I have another similar function that might be useful in Phobos as well.

"isBlank" and "isPresent". "isPresent" is just the opposite of "isBlank".

"isBlank" works like this:

* If it's a string - it's considered blank if it's empty or only contains white space

* If you can call "empty" on it - return the result

* If it's a reference type and it's null - return true

* Otherwise return false

-- 
/Jacob Carlborg

On 2013-02-14 13:20, Regan Heath wrote:

> Just a minor point from me.  I reckon the functionality you want can and
> should be built on top of std.getopt.
>
> As others have said you could either do this first and get it submitted
> to phobos, and then work on the other issues and getting Orbit itself in
> there.. or you can build this functionality into a module within Orbit
> and then work on getting that extracted as a separate module in phobos.
>
> The former delays ppl being able to use Orbit, the latter means more
> work down the line to refactor Orbit - tho hopefully this will just be
> an import declaration change, tho it may also include a slight API
> change if ppl are unhappy with the existing one.

Andrei said there's stuff he didn't want at all, like the "dstack" library. I don't know if he means in Phobos or in Orbit at all.

-- 
/Jacob Carlborg

On 2013-02-14 13:20, Regan Heath wrote:

> Just a minor point from me.  I reckon the functionality you want can and
> should be built on top of std.getopt.

The thing is that most of this is already present and working in the argument parser in Tango. The rest I've added myself. I don't feel too enthusiastic about redoing half of the work that's already been done in Tango.

-- 
/Jacob Carlborg

On Thursday, 14 February 2013 at 19:57:25 UTC, Jacob Carlborg wrote:
> On 2013-02-14 15:28, Steven Schveighoffer wrote:
>
>> Would this work?
>>
>> bool any(R)(R r) if(isInputRange!R) { return !r.empty;}
>
> Yes, I already have something similar. Actually I have this:
>
> @property bool any (T) (T value) if (__traits(compiles, { bool a = value.empty; }))
> {
>     return !value.empty;
> }

The only purpose of this is to make code more readable, correct? (The few extra keystrokes to write !a.empty seem negligable).

It fails at that, because "any" means something different to a lot of people, creating confusion as opposed to clarity.

On 2013-02-14 21:05, John Colvin wrote:

> The only purpose of this is to make code more readable, correct?

Yes, exactly.

> (The few extra keystrokes to write !a.empty seem negligable).
>
> It fails at that, because "any" means something different to a lot of
> people, creating confusion as opposed to clarity.

Yeah, I'm not perfectly satisfied with the name either.

-- 
/Jacob Carlborg

15-Feb-2013 00:03, Jacob Carlborg пишет:
> On 2013-02-14 13:20, Regan Heath wrote:
>
>> Just a minor point from me.  I reckon the functionality you want can and
>> should be built on top of std.getopt.
>>
>> As others have said you could either do this first and get it submitted
>> to phobos, and then work on the other issues and getting Orbit itself in
>> there.. or you can build this functionality into a module within Orbit
>> and then work on getting that extracted as a separate module in phobos.
>>
>> The former delays ppl being able to use Orbit, the latter means more
>> work down the line to refactor Orbit - tho hopefully this will just be
>> an import declaration change, tho it may also include a slight API
>> change if ppl are unhappy with the existing one.
>
> Andrei said there's stuff he didn't want at all, like the "dstack"
> library. I don't know if he means in Phobos or in Orbit at all.
>

I believe that the idea is that any amount of helpers is fine as long as they are private and don't obfuscate code. Phobos contains a lot tiny helpers that _might_ be useful but not exposed because of dubious general utility and potentially confusing names.

As far pushing good primitives into Phobos, it'd better be done one step at time and decoupled of the actual inclusion of Orbit (if we can agree on it being included) into say tools repo and being bundled with DMD.

-- 
Dmitry Olshansky

On 2013-02-14 21:14, Dmitry Olshansky wrote:

> I believe that the idea is that any amount of helpers is fine as long as
> they are private and don't obfuscate code. Phobos contains a lot tiny
> helpers that _might_ be useful but not exposed because of dubious
> general utility and potentially confusing names.
>
> As far pushing good primitives into Phobos, it'd better be done one step
> at time and decoupled of the actual inclusion of Orbit (if we can agree
> on it being included) into say tools repo and being bundled with DMD.

I agree that might be the best idea. But that is mostly for the "any" function and similar smaller utility functions. The bigger problems are like the serialization modules. Sure they could be put directly in Orbit as well. But I still got dependencies on Tango for stuff like XML, Zip, net and argument parsing.

-- 
/Jacob Carlborg

On Thursday, 14 February 2013 at 19:54:28 UTC, Jacob Carlborg wrote:
>> D has "any" (previously an overload of "canFind") as an algorithm that
>> finds whether at least one element of a range satisfies a condition,
>> otherwise writable as "!r.find!(a => condition).empty". The
>> convenience/mechanics/generality of the construct was enough
>> justification to add the algorithm. To claim that D already has the
>> negation of empty because one can write "r.any(a => true)" is, in my
>> opinion, an ill-posed argument.
>
> I just thought that we could add a default predicate to the "any" function.

Yes for a default predicate, BUT I think it should be "a => a" (that is, identity function) instead of "a => true". Same default predicate should be applied to "all" function as well. This way the behavior with boolean ranges would match the behavior of "any" and "all" at least in Python and Matlab (and apparently also Ruby).

On 2013-02-14 21:23, tn wrote:

> Yes for a default predicate, BUT I think it should be "a => a" (that is,
> identity function) instead of "a => true". Same default predicate should
> be applied to "all" function as well. This way the behavior with boolean
> ranges would match the behavior of "any" and "all" at least in Python
> and Matlab (and apparently also Ruby).

Right. But the problem with that is that a zero in D is considered false wheres in Ruby it's true. The only things that are false in Ruby is "nil" and "false".

-- 
/Jacob Carlborg

15-Feb-2013 00:18, Jacob Carlborg пишет:
> On 2013-02-14 21:14, Dmitry Olshansky wrote:
>
>> I believe that the idea is that any amount of helpers is fine as long as
>> they are private and don't obfuscate code. Phobos contains a lot tiny
>> helpers that _might_ be useful but not exposed because of dubious
>> general utility and potentially confusing names.
>>
>> As far pushing good primitives into Phobos, it'd better be done one step
>> at time and decoupled of the actual inclusion of Orbit (if we can agree
>> on it being included) into say tools repo and being bundled with DMD.
>

> I agree that might be the best idea. But that is mostly for the "any"
> function and similar smaller utility functions. The bigger problems are
> like the serialization modules. Sure they could be put directly in Orbit
> as well. But I still got dependencies on Tango for stuff like XML, Zip,
> net and argument parsing.

Then there are these ways forward IMHO:
a) Admit that tango for D2 exists (easy) and bundle it with DMD (the hard/not likely/inconvenient part)
b) Agree that we need to port it and issue a call to port/re-write required facilities for Orbit on top of phobos/curl. This means pulls against Orbit repo not phobos BTW.
c) Forget about Orbit and try something else, like Dub?

About serialization (that seems the biggest roadblock) - what exactly does Orbit need it for? Maybe it can be decoupled and/or easily re-written by hand until Orange or similar stuff gets into Phobos.

Regardless I think reducing dependencies is the important for inclusion of any new component into the "D core".

-- 
Dmitry Olshansky