On 2013-02-13, 21:19, Walter Bright wrote:

> On 2/12/2013 11:34 PM, Jacob Carlborg wrote:
>> 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++.
>>
>
>
> The any in std.algorithm is defined:
>
> --------------
> bool any(alias pred, Range)(Range range);
>
> Returns true if and only if a value v satisfying the predicate pred can be found in the forward range range. Performs Ο(r.length) evaluations of pred.
> --------------
>
> I see that as very different from !empty.

In C#, the Any function may be called with or without a predicate.
With one, it works as what is already in std.algorithm. Without, it works
like Jacob describes.

-- 
Simen

On 2013-02-15, 17:14, Jacob Carlborg wrote:

> On 2013-02-15 15:28, Steven Schveighoffer wrote:
>
>> That is an overstatement.  I'm pretty sure people are interested in
>> having serialization in Phobos.
>
> It's been in the review queue for over two years. I've pushed for it a couple of times to get it reviewed but got no answers. I've basically given up now.

It's not listed here:

http://wiki.dlang.org/Review_Queue

I'm not sure about the intricacies of adding something to the list (this
should probably be in the wiki somewhere), so I took the liberty of
adding it. If nobody else steps up, I guess I'll have to pretend to be a
sensible human and act like a review manager too.

Labeled it std.serialization, because I think std.orange might be a tad
opaque to newcomers.

-- 
Simen

On 2013-02-15, 14:38, Marco Leise wrote:

> Am Thu, 14 Feb 2013 02:00:20 -0800
> schrieb Walter Bright <newshound2@digitalmars.com>:
>
>> The trouble is, where do you stop adding trivia? How about this one:
>>
>>     T addThree(T t) { return t + 3; }
>>
>> ?
>
> I thought that's _why_ we have ++ and --.

Indeed. ++++++t is just as readable as the above. :p

-- 
Simen

On 2013-02-15, 17:14, Jacob Carlborg wrote:

> On 2013-02-15 15:28, Steven Schveighoffer wrote:
>
>> That is an overstatement.  I'm pretty sure people are interested in
>> having serialization in Phobos.
>
> It's been in the review queue for over two years. I've pushed for it a couple of times to get it reviewed but got no answers. I've basically given up now.


-- 
Simen

On 2013-02-15, 18:20, Andrei Alexandrescu wrote:

> On 2/15/13 11:14 AM, Jacob Carlborg wrote:
>> On 2013-02-15 15:28, Steven Schveighoffer wrote:
>>
>>> That is an overstatement. I'm pretty sure people are interested in
>>> having serialization in Phobos.
>>
>> It's been in the review queue for over two years. I've pushed for it a
>> couple of times to get it reviewed but got no answers. I've basically
>> given up now.
>
> Here's what I think - in order to add things to Phobos and generally the standard distribution you must revamp your entire attitude.
>
> I have a lot of sympathy because years ago I was in the exact position. I'd written the Loki library for C++ that included many components deserving inclusion in C++'s standard library. As a first step I asked for Loki to be included in Boost. The attempt was met with interest but it soon became obvious that I'd need to go through a difficult review and make quite extensive adaptations and changes to the library in order to be considered. My attitude was "take it or leave it" and that just didn't work (and in retrospect, for the better).
>
> Part of the proposal was a policy-based smart pointer that was superior in every way I could think of to other candidates. Yet the proposers of those candidates were willing to go through the hard work of improving and streamlining their proposals, to the point they got into Boost and ultimately into the standard. With time the relative deficiencies of that proposal was reduced by adding more kinds of smart pointers, so in the end it all got where it is today. In contrast, I was busy with my Ph.D. research so I didn't have the time to file away all rough edges.
>
> That was a good lesson to learn. Applied to the situation of today, to get anything into the D programming language requires determination, humility, and willingness to take criticism and convert it positively. I think assuming that Orbit is a great finalized design that others fail to appreciate is definitely the wrong starting point. The right starting point is asking for feedback, integrate it, and ask again, all in a loop.

Very good. Thank you.


-- 
Simen

On 2013-02-15, 19:53, Jesse Phillips wrote:

> On Friday, 15 February 2013 at 16:54:06 UTC, Simen Kjaeraas wrote:
>> It's not listed in the review queue on the wiki:
>>
>> http://wiki.dlang.org/Review_Queue
>
> Well than that isn't complete:
>
> http://www.prowiki.org/wiki4d/wiki.cgi?ReviewQueue
>

Indeed. I was under the impression all of the old wiki should have
been migrated, but that is apparently not the truth. It is now, though.

-- 
Simen

On 2013-02-16, 15:42, Jacob Carlborg wrote:

> Well lucky you.

Please, relax. Trust me, we understand you feel miffed. Your attitude here
is hurting your case, and that's unnecessary.


> I haven't even got a proper review for Orange. I got some comments and feedback but no formal review.

In December 2011[1] there was a push for review, where you basically said
it's not ready yet, referring to a September post[2] asking for a
pre-review. Is this all activity there has been? This happened during
christmas, which might explain a lack of responses.

I understand you want to be sure it'll be included before you do the work
that's necessary for it to be included, but there's a bit of chicken-and-
egg here.

And trust me, we want to see serialization in Phobos. You're close. Have
faith (and that comes from an atheist :p).


> Saying something that I don't want to change anything is plain wrong. I got feedback that slices weren't properly deserialized and that it could be problems if the serializer was templated on the archive. That caused me to completely refactor the library, mostly internal.
>
> I also got the suggestion to allow to set a serializer for a type both for a given instance of the serializer and globally. This also got implemented.
>
> The only thing I haven't implemented that got suggested is support for versions. I haven't done that because I think that this doesn't need direct support because that can be handled by performing custom serialization of a type.
>
> The only thing that could have caused problem is that it also supports D1/Tango. But I have said from day one that if it gets accepted I will remove any traces of D1 and Tango. Most of the code is completely independent of D1/Tango and the code which has dependencies is very local that has nothing to do with the actual design of the serializer.

So it's ready for a review now, not just a pre-review? Then tell us.
Get a review manager to read through it. Badger him to post it for review.
Yup, it's more work than sitting around hoping it will happen, but it has
a much higher chance of success.


[1]: http://forum.dlang.org/thread/j62f5p$1h07$1@digitalmars.com
[2]: http://forum.dlang.org/thread/irscfdwwkapwghfouhom@dfeed.kimsufi.thecybershadow.net
-- 
Simen

On 2013-03-20 17:31, Simen Kjaeraas wrote:

> So it's ready for a review now, not just a pre-review? Then tell us.
> Get a review manager to read through it. Badger him to post it for review.
> Yup, it's more work than sitting around hoping it will happen, but it has
> a much higher chance of success.

I have removed any Tango dependencies, D1 related code and other code that wasn't really necessary. But I'm going to see if I can make the serialization of arrays faster first. Or I should just ask for a review to get help with that.

-- 
/Jacob Carlborg

On 2013-03-20, 20:20, Jacob Carlborg wrote:

> On 2013-03-20 17:31, Simen Kjaeraas wrote:
>
>> So it's ready for a review now, not just a pre-review? Then tell us.
>> Get a review manager to read through it. Badger him to post it for review.
>> Yup, it's more work than sitting around hoping it will happen, but it has
>> a much higher chance of success.
>
> I have removed any Tango dependencies, D1 related code and other code that wasn't really necessary. But I'm going to see if I can make the serialization of arrays faster first. Or I should just ask for a review to get help with that.

I say do the review, make things faster afterwards. There'll always be
stuff you can do better, and it's not really harder to do after a review.
Plus, that will get it into Phobos faster.

Sorry about necroing the thread, btw. My mail client ferked up and hadn't
sent mails for a few weeks.

-- 
Simen

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

But "present" and "blank" aren't opposites in English. "isNonBlank" or "isNotBlank" are opposites of "isBlank", but "isPresent" would be the opposite of "isAbsent." It seems almost meaningless in the context of a string predicate --- If I saw it in code, I would guess it meant "not a null reference."

Similarly with "any" vs. "empty." I would think that "any" is synonymous with "some" and therefore should be the opposite of either "none" or "all" (leaning toward "all," given the commonality of some/all predicates in other languages, and the exists/forall concepts in predicate logic).

Regardless of their name, I would not like to see functions like these in Phobos. It's already challenging enough to keep the signature of the larger Phobos modules in one's head. Adding functions like these just adds noise... expressions like (!s.empty) are perfectly readable.

Graham


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