On Tuesday, 20 August 2013 at 20:06:12 UTC, Jacob Carlborg wrote:
> Would calling it "archiver" or some other name be better?

Almost certainly, yes. An "archive" is something you put data into, not something that puts data somewhere else. ;)

David

On 8/20/2013 1:06 PM, Jacob Carlborg wrote:
> I guess it could be called "archiver", or do you have a better suggestion?

That sounds perfect.


>> Some exposition of this is necessary, along with some comments along the
>> line that the package provides a generic archiving interface, and a
>> couple implementations X and Y of that interface, and that other
>> implementations such as Z, the zip archiver, are possible.
>
> I don't understand what's so confusing.
>
> "This is the interface all archive implementations need to implement to be able
> to be used as an archive with the serializer".

I tend to think in terms of concrete examples, rather than abstract concepts. Hence my suggestion.

On Tuesday, 20 August 2013 at 19:34:54 UTC, Jacob Carlborg wrote:
> I have been planning to add a function like that but just haven't got around doing it. This is just a convenience function that is easy to add.

Cool, as I have said it is not something critical that would impact my voting, just personal preferences.

> * The serializer does have state. It stores information about what's serialized and keep track that an object is not stored more than once in the archive and similar things.

Ah, makes sense. Well I guess then this is the power for robustness in data structure support and nothing can be done but hide it behind convenience wrappers. Sad but true :)

P.S. Right now most important (and probably only really important) thing is range API. I think it is worth focusing on it and getting through the voting stage - actual merge can happen at any time you / Phobos devs are satisfied with implementation state, it does not require major community attention.

On Tuesday, 20 August 2013 at 10:51:25 UTC, Johannes Pfau wrote:
> Am Tue, 20 Aug 2013 10:40:57 +0200
> schrieb "ilya-stromberg" <ilya-stromberg-2009@yandex.ru>:
>> We can use InputRange like this:
>> 
>> import std.file;
>> auto archive = new Archive()
>> Serializer(archive).serialize(object);
>> //Archive implements InputRange for ubyte[]
>> write("file", archive);
>
> Yes, InputRange is more flexible, but it's also more difficult to
> implement and less efficient:
> What happens between the 'serialize' and the 'write' call? Archive
> has to cache the data, either the original object or the final
> produced data in an ubyte[] buffer.

No, Archive have to do NOTHING. 'serialize' call must only store pointer to the object - without this requirement we can't have lazy range. Serialization starts afrer 'write' call, and ArchiveInputRange have to store current serialization state (like Serializer in current implementation).

On Tuesday, 20 August 2013 at 15:07:39 UTC, Tyler Jameson Little wrote:
> On Tuesday, 20 August 2013 at 13:44:01 UTC, Daniel Murphy wrote:
>> "Dicebot" <public@dicebot.lv> wrote in message
>> news:luhuyerzmkebcltxhgjj@forum.dlang.org...
>>>
>>> What I really don't like is excessive amount of object in the API. For example, I have found no reason why I need to create serializer object to simply dump a struct state. It is both boilerplate and runtime overhead I can't justify. Only state serializer has is archiver - and it is simply collection of methods on its own. I prefer to be able to do something like `auto data = serialize!XmlArchiver(value);`
>>>
>>
>> I think this is very important.  Simple uses should be as simple as
>> possible.
>
> +1
>
> This would enhance the 1-liner: write("file", serialize!XmlArchiver(InputRange));
>
> We could even make nearly everything private except an isArchiver() template and serialize!().

It will be great! Also, whith Uniform Function Call Syntax (UFCS) it can be better:
InputRange.serialize!XmlArchiver.zip.save("file");

Also, we can provide a default Archiver type, for example XmlArchiver or BinaryArchiver:
auto serialize(Archiver = BinaryArchiver, R)(R InputRange);
//Use default Archiver type
InputRange.serialize.zip.save("file");

On 2013-08-21 08:45, ilya-stromberg wrote:

> Also, we can provide a default Archiver type, for example XmlArchiver or
> BinaryArchiver:
> auto serialize(Archiver = BinaryArchiver, R)(R InputRange);
> //Use default Archiver type
> InputRange.serialize.zip.save("file");

That's the plan.

-- 
/Jacob Carlborg

On 2013-08-21 02:09, Dicebot wrote:
> P.S. Right now most important (and probably only really important) thing
> is range API. I think it is worth focusing on it and getting through the
> voting stage - actual merge can happen at any time you / Phobos devs are
> satisfied with implementation state, it does not require major community
> attention.

Yes, but now there have been quite a lot suggestions for how the range API should look like that I'm even more confused. I'll think a start a new thread for this.

-- 
/Jacob Carlborg

On Wednesday, 21 August 2013 at 06:55:56 UTC, Jacob Carlborg wrote:
> On 2013-08-21 02:09, Dicebot wrote:
>> P.S. Right now most important (and probably only really important) thing
>> is range API. I think it is worth focusing on it and getting through the
>> voting stage - actual merge can happen at any time you / Phobos devs are
>> satisfied with implementation state, it does not require major community
>> attention.
>
> Yes, but now there have been quite a lot suggestions for how the range API should look like that I'm even more confused. I'll think a start a new thread for this.

Try to read the article:
http://wiki.dlang.org/Component_programming_with_ranges
It has got a lot of range examples, including std.range, std.algorithm and creation of new ranges.

On Wednesday, 21 August 2013 at 06:55:56 UTC, Jacob Carlborg wrote:
> Yes, but now there have been quite a lot suggestions for how the range API should look like that I'm even more confused. I'll think a start a new thread for this.

Sure. I have already written my opinion on this but getting attention / opinion of some Phobos developers on this topic could have been valuable.