August 14, 2013
On Wednesday, 14 August 2013 at 14:34:58 UTC, Jacob Carlborg wrote:
> On 2013-08-14 16:15, ilya-stromberg wrote:
>
>> I think we should avoid mixins as much as it possible.
>> UDA @nonSerialized looks much better, so I think we should use it.
>> Of course, we can leave template NonSerialized(Fields...) for backwards
>> compatible with Orange and, maybe, deprecate it.
>
> Of course UDA's should be the primary use for this. The question is should NonSerialized be included at all? Should it be included and deprecated or should it just be included?

I did not use Orange at all.
But the most terrible for library is losing backwards compatiblity. So, if Orange uses NonSerialized, we have to include it. We can just add documentation notice that NonSerialized will be deprecated after, for example, 6 months.
August 14, 2013
On Wednesday, 14 August 2013 at 14:50:45 UTC, ilya-stromberg wrote:
> I did not use Orange at all.
> But the most terrible for library is losing backwards compatiblity. So, if Orange uses NonSerialized, we have to include it. We can just add documentation notice that NonSerialized will be deprecated after, for example, 6 months.

std.serialization is not Orange and should not be considered as one. Once it is included into Phobos it is a brand new library and must be treated as such, no matter what origin it has. Users of Orange expect compatibility from Orange, not Phobos.
August 14, 2013
On Wednesday, 14 August 2013 at 14:34:58 UTC, Jacob Carlborg wrote:
> On 2013-08-14 16:15, ilya-stromberg wrote:
>
>> I think we should avoid mixins as much as it possible.
>> UDA @nonSerialized looks much better, so I think we should use it.
>> Of course, we can leave template NonSerialized(Fields...) for backwards
>> compatible with Orange and, maybe, deprecate it.
>
> Of course UDA's should be the primary use for this. The question is should NonSerialized be included at all? Should it be included and deprecated or should it just be included?

I don't think it should be included. The UDAs replace it nicely, and though std.serialization would be essentially Orange it's still a different library. Some breaking changes are to be expected, and in this case I think worth-while. Having multiple ways of specifying options such as non-serialized is confusing. If you had UDAs available to you from the start, would you have included the mixins? If not, why include them now? This is essentially a fresh start, one inside Phobos rather than a separate library.
August 14, 2013
On 2013-08-14 17:08, Kapps wrote:

> If you had UDAs available to you from the start, would you have included the mixins?

No.

> If not, why include them now?

You do have a point.

-- 
/Jacob Carlborg
August 14, 2013
On 8/14/13 1:48 AM, Jacob Carlborg wrote:
> On 2013-08-14 10:19, Tyler Jameson Little wrote:
>>    - I would to serialize to a range (file?) and deserialize from a
>> range (file?)
>
> The serialized data is returned as an array, so that is compatible with
> the range interface, it just won't be lazy.

This seems like a major limitation. (Disclaimer: I haven't read the documentation yet.)

Andrei

August 14, 2013
On 2013-08-14 18:25, Andrei Alexandrescu wrote:

> This seems like a major limitation. (Disclaimer: I haven't read the
> documentation yet.)

The data is built up as a DOM (with the XmlArchive) using std.xml. I should I get a range out of that?

-- 
/Jacob Carlborg
August 14, 2013
On 8/14/13 12:10 PM, Jacob Carlborg wrote:
> On 2013-08-14 18:25, Andrei Alexandrescu wrote:
>
>> This seems like a major limitation. (Disclaimer: I haven't read the
>> documentation yet.)
>
> The data is built up as a DOM (with the XmlArchive) using std.xml. I
> should I get a range out of that?

I'm thinking some people may need to stream to/from large files and would find the requirement of in-core representation limiting.

Andrei

August 14, 2013
On 2013-08-14 21:11, Andrei Alexandrescu wrote:

> I'm thinking some people may need to stream to/from large files and
> would find the requirement of in-core representation limiting.

Yes, I understand that. But currently I'm limited by std.xml.

-- 
/Jacob Carlborg
August 14, 2013
On Wed, Aug 14, 2013 at 09:23:50PM +0200, Jacob Carlborg wrote:
> On 2013-08-14 21:11, Andrei Alexandrescu wrote:
> 
> >I'm thinking some people may need to stream to/from large files and would find the requirement of in-core representation limiting.
> 
> Yes, I understand that. But currently I'm limited by std.xml.
[...]

Would it be possible to present a range *interface*, that currently just converts to array (or aliases to array if it's already an array), so that in the future, when std.xml is revamped to use ranges, existing code will automatically reap the benefits?


T

-- 
Today's society is one of specialization: as you grow, you learn more and more about less and less. Eventually, you know everything about nothing.
August 14, 2013
On 2013-08-14 21:40, H. S. Teoh wrote:

> Would it be possible to present a range *interface*, that currently just
> converts to array (or aliases to array if it's already an array), so
> that in the future, when std.xml is revamped to use ranges, existing
> code will automatically reap the benefits?

Since std.xml returns the data as a string, you mean I just forward the range interface to this string?

-- 
/Jacob Carlborg