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 [email protected] 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 [email protected] 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 evalEmpire/Mite#5 and herehttps://github.com/evalEmpire/Mite/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.