develooper Front page | perl.perl5.porters | Postings from October 2014

Re: [perl #122870] Bleadperl v5.21.3-586-g56cd2ef breaks YVES/Data-Dump-Streamer-2.38.tar.gz

Thread Previous | Thread Next
October 1, 2014 11:51
Re: [perl #122870] Bleadperl v5.21.3-586-g56cd2ef breaks YVES/Data-Dump-Streamer-2.38.tar.gz
Message ID:
On 1 October 2014 02:13, Father Chrysostomos via RT <> wrote:

> DDS is subclassing B::Deparse and overriding methods.  (Almost all its
> methods are undocumented.)
> B::Deparse::padname returns a string containing a variable name.
> B::Deparse::padname_sv (which padname calls) returns the B::SV object that
> the variable name is derived from.
> Data::Dumper::Streamer::Deparser overrides padname, in order to change the
> name of the lexical variable.
> Commit 56cd2ef8a changes some code that deparses lexicals (pp_pasv) and
> makes it call padname_sv directly, instead of padname (since it needs the
> padname_sv now).  It (or rather maybe_my) then calls ->PVX on the pad name
> SV, which was previously padname’s job.
> Should I adjust B::Deparse to make it call ->padname to get the pad name
> (which would result in some oddly-arranged code), or should
> Data::Dump::Streamer account for the new set-up?
I would prefer not having to change DDS. In particular it would mean DDS
has to support two different ways to do this, along with all the machinery
to select the appropriate methodology. Personally I think that exports the
"oddly arranged code" problem to DDS in a way that makes the problem much
worse. There is already far too much of this type of version specific logic
in DDS.

> I’m leaning toward the latter.  DDS could override padname_sv to return a
> subclass of B::SV that swaps out a different name in a PVX override, just
> as the padname override currently swaps out the name.

If we *are* going to change DDS then I would rather do it by changing
Deparse to have an API that allows a caller to override naming in general,
ideally everything, methods, subs, vars, etc.

Then DDS (and others that do this trick) would use that API going forward,
and when people changed the internals Deparse's internal API's would
abstract that from the user. Such a scenario IMO would justify changing DDS
to support old and new Deparse implementations. Doing so just to avoid some
"oddly arranged code" just punts the problem down the road. What happens on
the next release where this code in Deparse is changed?

In general I feel that DDS doesnt do anything controversial, it merely
tries to accurately and reliably dump a data set as Perl statements such
that when those statements are executed the resulting data structure is
functionally identical to the original. Thus I feel pretty strongly that
whatever DDS does do that "cheats" is something that we should already
offer API's to do properly.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About