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 12:11
Re: [perl #122870] Bleadperl v5.21.3-586-g56cd2ef breaks YVES/Data-Dump-Streamer-2.38.tar.gz
Message ID:
On 1 October 2014 13:51, demerphq <> wrote:

> 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.

And to follow up on that point, there are at least a small handful of
routines that migrated from DDS into the core.


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

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