Add Terse()

[schwern]

This adds Terse(), like in Data::Dumper, to disable the "$VAR = " part of the dump. This makes DDS more flexible to serialize and deserialize data structures.

I'm quite sure there's a ton of special cases I missed.

[schwern]

This would close https://rt.cpan.org/Public/Bug/Display.html?id=45420

[demerphq]

On 17 March 2014 23:59, Michael G. Schwern notifications@github.com wrote:

This adds Terse(), like in Data::Dumper, to disable the "$VAR = " part of the dump. This makes DDS more flexible to serialize and deserialize data structures.

I didnt support this mode because it can't handle cyclic data structures and other forms of "fixup" statements.

If the intent is to make it easier to serialize or deserialize then adding a mode to autowrap the output in a do { } makes more sense to me:

do { $VAR = ....; fixup($VAR); $VAR; };

Possibly what would be best would be to output the do { } and var declaration and then remove it afterwards if there were no fixup statements.

If this intended for more readable dumps then that is a different discussion.

I have to admit that using DDS for serialization/deserialization is surprising to me given its extremely poor performance. It is aimed at readability and handling "anything", not at speed. Which of the features in DDS is making you use this over something designed for serialization like Sereal?

Yves

[schwern]

I'm using this for a thing where serialization performance does not matter, but accuracy does: Mite-Compiler. Serialization would happen at module build time, not compile nor runtime. Details here and here. DDS preserves the lexical environment in a way no other module does. I'm willing to be convinced this is a bad idea.

The do trick seems like a good work around.

Given this is going to do much more than "don't use names", the functionality needs a better name. One that describes the intent than the mechanics. For_Serialization() would be my first idea. Or instead of calling Out() it calls Freeze().

[demerphq]

On 18 March 2014 23:35, Michael G. Schwern notifications@github.com wrote:

I'm using this for a thing where serialization performance does not matter, but accuracy does: Mite-Compilerhttps://github.com/schwern/Mite-Compiler. Serialization would happen at module build time, not compile nor runtime. Details here https://github.com/schwern/Mite-Compiler/issues/5 and herehttps://github.com/schwern/Mite-Compiler/issues/4. DDS preserves the lexical environment in a way no other module does. I'm willing to be convinced this is a bad idea.

Interesting, thanks. I am surprised this has practical utility, but at the same time happy it does. (And a bit regretful i never got around to rewriting it in C)

The do trick seems like a good work around.

Given this is going to do much more than "don't use names", the functionality needs a better name. One that describes the intent than the mechanics. For_Serialization() would be my first idea. Or instead of calling Out() it calls Freeze().

Hrm. Freeze() seems a poor choice given the popularity of the term for other serialization related purposes. Perhaps we can leverage the point that we are taking a set of statements and turning them into an expression using do {} and call it something like AsExpr() or As_Expression() or something along those lines? For_Serialization doesn't seem to encapsulate the point properly, and its long. :-)

Cheers, yves

perl -Mre=debug -e "/just|another|perl|hacker/"

[schwern]

AsExpr() sounds descriptive to me.

It occurs to me that DDS might not be usable by Mite because things like fixup() and make_ro() create a dependency on DDS. That said, I think the only need I have for preserving lexical context is for code references, and I have a way to deal with that which doesn't involve DDS. For data references Data::Dumper should work fine... though data structures containing code references will be a special case.