Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Data-Printer CPAN distribution.

Report information
The Basics
Id: 84103
Status: resolved
Priority: 0/
Queue: Data-Printer
People
Owner: Nobody in particular
Requestors: frioux [...] gmail.com
Cc:
AdminCc:
Bug Information
Severity: Critical
Broken in: 0.35
Fixed in: (no value)

History Show all quoted text
  Wed Mar 20 16:02:58 2013 frioux [...] gmail.com - Ticket created
Subject: Options are global
Sadly this is probably going to be pretty hard to fix, but basically your options are global to the interpreter. That's fine when Data::Printer is exclusively used by the developer for ad-hoc debugging, but if, for instance, you wanted to use Data::Printer to format error messages in a log, the options set there are applied everywhere. To be clear, this code fails: perl -E'package A; use Data::Printer alias => "_dump";' -E'package main; use Data::Printer; my $x = {}; p $x' FWIW I think the best solution would be to do something similar to what we did in Log::Contextual, where under the hood there is an object with the options applied. The object could, in this case, probably be stored in a hash where the key is the package that did the importing. Then "package Foo; use Data::Printer coloring => 0" becomes sugar for: "$printer_for_package{Foo} = Data::Printer::Object->new( coloring => 0 );" and p just proxies to that object. If I get a chance I may factor out the object as that would be sufficient for my use case.
  Fri May 18 00:11:08 2018 garu [...] cpan.org - Correspondence added
Hey Frew! Long time no see :) After a very (very!) long time, I finally got around to rewrite DDP from scratch with an underlying object and much more. I'm moving the rest of the discussion to github's https://github.com/garu/Data-Printer/issues/46 but let me just say this, straight from CPAN Data-Printer-0.99_007 and github master: $ perl -Ilib -E'package A; use Data::Printer alias => "_dump";' -E'package main; use Data::Printer; my $x = {}; p $x' {} Thanks again! You're the one who inspired this rewrite :) Cheers! garu On Wed Mar 20 16:02:58 2013, frew wrote: Show quoted text
> Sadly this is probably going to be pretty hard to fix, but basically > your options are global to the interpreter. That's fine when > Data::Printer is exclusively used by the developer for ad-hoc > debugging, but if, for instance, you wanted to use Data::Printer to > format error messages in a log, the options set there are applied > everywhere. To be clear, this code fails: > > perl -E'package A; use Data::Printer alias => "_dump";' -E'package > main; use Data::Printer; my $x = {}; p $x' > > FWIW I think the best solution would be to do something similar to > what we did in Log::Contextual, where under the hood there is an > object with the options applied. The object could, in this case, > probably be stored in a hash where the key is the package that did the > importing. Then "package Foo; use Data::Printer coloring => 0" > becomes sugar for: "$printer_for_package{Foo} = Data::Printer::Object-
> >new( coloring => 0 );" and p just proxies to that object.
> > If I get a chance I may factor out the object as that would be > sufficient for my use case.
  Fri May 18 00:11:08 2018 The RT System itself - Status changed from 'new' to 'open'
  Fri May 18 00:11:09 2018 garu [...] cpan.org - Status changed from 'open' to 'resolved'