On 2013-02-15 16:22, Sean Kelly wrote:

> Tango is distributed under an incompatible license. A license that unfortunately can't be changed
> because many of the Tango authors are MIA.

It does not need to be changed. It just needs to be included in the distribution of DMD. Nothing that uses DMD or Phobos will be affected. Well, that's actually only necessary if the source code of Orbit itself is included with DMD. Apparently the source code for RDMD is not included.

> There's nothing political involved. And if the dependency is
> just on a JSON module, that's easy to resolve.

The large dependencies it has are: XML, net, ZIP and argument parsing. Then there are some utility functions, but they are the least of the problem.

> We have a new std.json module in the queue anyway, don't we?

That's another problem. In Tango there is working code right now, not possibly some time in the future.

-- 
/Jacob Carlborg

On 2013-02-15 21:25, Jonathan M Davis wrote:

> We have enough problems when we _do_ review things thoroughly. But added the
> review process was one of the best things that we've done. The code quality of
> submissions has improved considerably. And as the writer of the first module to
> go through the process (std.datetime), I can testify that it helped
> considerably in improving it. What we ended up with was actually quite
> different in a number of places from what was originally implemented, and it's
> far better for it.
>
> The main thing that we may want to do differently in the future is to give new
> modules more of an incubation period where they're distributed with Phobos but
> are clearly marked as still being experimental so that we can make further
> modifications when they start actually getting used and issues crop up. And
> then after a few releases, we actually start treat its API as being as close
> to frozen as the rest of Phobos is. But regardless, we certainly don't want to
> lower the bar of admission. It's what's going to ensure that Phobos is a solid
> standard library.

I completely agree with that and I don't want to change anything of that. I just want you to broaden your minds a bit. Like why a third party library cannot be included.

BTW, have any of the tools in the tools repository been through a review process? I'm not saying that they should or shouldn't, just asking.

-- 
/Jacob Carlborg

On 2013-02-15 17:56, Jesse Phillips wrote:

> For XML I suggest trying http://www.dsource.org/projects/xmlp/wiki
> I tend not to like working in XML and this library doesn't change that,
> but if someone is interested in getting XML added to Phobos I highly
> suggest using this and writing bugs for improvements so that we can get
> a library that is satisfactory into Phobos.

Since I'm already have a working XML module I don't want to replace it with anything else without knowing it is/will be included into Phobos. If I'm going to replace a module I don't want to do it more than once.

> As for serialization I wouldn't say no one is interested:
> http://wiki.dlang.org/Review_Queue
> Personally I'm just not in a good position to review and give feedback.

Anyone should be able to contribute with suggestions for how the API should look like and work as long as they have any interest (possibly even without interest) in the module. Also verifying that the documentation is good enough.

-- 
/Jacob Carlborg

On 2013-02-15 18:16, nazriel wrote:
> As for XML module, we have this shiny candy:
>
> http://opticron.no-ip.org/svn/branches/libdxml2/xml.d
>
>  From what author says it is semi phobos ready.
> Already supports up to BidirectionalRanges.
>
> Author got a bit tired of fighting ranges, so if somebody could help,
> probably we could get it into phobos quite quick.
>
> As a side note, I have used it in several projects already, and I am
> really happy with this (libdjson is also worth a note:
> http://opticron.no-ip.org/svn/branches/libdjson/json.d)

As I said in a previous post:

"Since I'm already have a working XML module I don't want to replace it
with anything else without knowing it is/will be included into Phobos.
If I'm going to replace a module I don't want to do it more than once."

-- 
/Jacob Carlborg

On Thursday, 14 February 2013 at 11:58:13 UTC, Jacob Carlborg wrote:
> On 2013-02-14 10:46, Walter Bright wrote:
>
>> I don't understand why one would go around the horn to just check for
>> !empty.
>
> I've tried to explain, it shows what the intention is.
>
> Instead of "str.length == 0" I use "str.empty". Instead of "!str.empty" I like to use "str.any".
>
> It's not a big deal but I would need to change quite a lot of code if "str.any" isn't allowed.

I totally agree with Walter, it adds useless cognitive load. I thoroughly hate it. I would need to have to look at the doc to know what any means, while !empty, everyone already knows it. And I don't want D to be another Perl, where one can write the same thing in ten different manners, so that it's impossible to recognize patterns or a common style.

On Thursday, 14 February 2013 at 20:01:37 UTC, Jacob Carlborg wrote:
> 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

What does isBlank() return with tabs ?

I don't like having two functions doing the same thing, so isBlank() may be useful, isPresent() only adds cognitive overload and mere chaos to the code base (because someone is going to use both at the same time in the same function, making the code harder to understand).

On Thursday, 14 February 2013 at 10:01:21 UTC, Walter Bright wrote:
> On 2/14/2013 12:32 AM, bearophile wrote:
>> Walter Bright:
> A good interface design has the *minimum* number of functions out of which anything else can be built. Functions that are recombinations of other functions in the same interface do not belong in that interface.
>
> It's tempting to create kitchen sink abstractions, but they really are a bad idea.

Yes, it actually makes reading code *harder* for everyone but the writer, because the code ends up lacking consistency.

On 2013-02-16 19:23, SomeDude wrote:

> What does isBlank() return with tabs ?

Tabs are considered whitespace so it would return "true".


> I don't like having two functions doing the same thing, so isBlank() may
> be useful, isPresent() only adds cognitive overload and mere chaos to
> the code base (because someone is going to use both at the same time in
> the same function, making the code harder to understand).

Sure, both does not have to be included.

-- 
/Jacob Carlborg

On 2/16/2013 10:35 AM, SomeDude wrote:
> On Thursday, 14 February 2013 at 10:01:21 UTC, Walter Bright wrote:
>> On 2/14/2013 12:32 AM, bearophile wrote:
>>> Walter Bright:
>> A good interface design has the *minimum* number of functions out of which
>> anything else can be built. Functions that are recombinations of other
>> functions in the same interface do not belong in that interface.
>>
>> It's tempting to create kitchen sink abstractions, but they really are a bad
>> idea.
>
> Yes, it actually makes reading code *harder* for everyone but the writer,
> because the code ends up lacking consistency.

My own experience is it makes it harder for the writer, too :-)

Also, it often takes several iterations to discover just what the right minimum set is. Nobody gets it right the first time.

On Saturday, 16 February 2013 at 15:13:18 UTC, Jacob Carlborg wrote:
> On 2013-02-15 18:16, nazriel wrote:
>> As for XML module, we have this shiny candy:
>>
>> http://opticron.no-ip.org/svn/branches/libdxml2/xml.d
>>
>> From what author says it is semi phobos ready.
>> Already supports up to BidirectionalRanges.
>>
>> Author got a bit tired of fighting ranges, so if somebody could help,
>> probably we could get it into phobos quite quick.
>>
>> As a side note, I have used it in several projects already, and I am
>> really happy with this (libdjson is also worth a note:
>> http://opticron.no-ip.org/svn/branches/libdjson/json.d)
>
> As I said in a previous post:
>
> "Since I'm already have a working XML module I don't want to replace it
> with anything else without knowing it is/will be included into Phobos.
> If I'm going to replace a module I don't want to do it more than once."


I wasn't talkig directly to you. Just putting KXML as an option for new std.xml
I agree that switching to kxml at this point would be totally pointless for you.