Data::Dumper Feature Request: CondenseRanges option #15069
Comments
From @kentfredricThere's a few features that exist in a few other Dumper tools that are simple enough that I imagine Data::Dumper can steal them. One of these is the trick Data::Dump does to condense ranges. Data::Dump recognises arrays of length >= 3 items that consist of monotonic integral steps and simplifies them to a range expression: For [1,2,3,4,5,6,7,8,9, 10], where Data::Dumper presently spews 10 lines on indentation levels other than 0, Data::Dump elegantly emits [ 1 .. 10 ] Obviously this is a feature that would be opt-in, as anything currently relying on string comparison of dumped structures in the wild randomly changing would be bad. Why a feature for Data::Dumper and not "Just use the other module"? The other module doesn't do sub { } deparsing, which somewhat limits the ability to get both sub deparsing and simplified lists. Data::Dump also only handles forward ranges, and I think we can possibly do a better job, and maybe support In a perfect world it could simplify any OEIS entry, but I can settle for a few higher-frequency common cases. Flags: Site configuration information for perl 5.22.0: Configured by kent at Fri Jun 19 08:03:55 NZST 2015. Summary of my perl5 (revision 5 version 22 subversion 0) configuration: @INC for perl 5.22.0: Environment for perl 5.22.0: |
From @jkeenanOn Sat, 05 Dec 2015 01:24:40 GMT, kentfredric wrote:
This ticket has received no comments or replies since it was first posted in December 2015. Lack of comment on a new feature request usually means that people have (silently) made the judgment: "The benefit of this feature does not outweigh the cost of creating and maintaining it." I suspect that's the case here. Data::Dumper poses maintenance problems because it has both "pure perl" and XS versions. New features would have to be implemented both ways. The people who can grok the XS code only have the time to keep up with critical bugs. I doubt they have time to implement additional features -- and then maintain them. In this situation you're more likely to get the new functionality if you do it first as a new CPAN distribution. If that CPAN distribution is well received, then perhaps it could be brought into core in future years. For that reason I recommend that we close this ticket. Thank you very much. -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @kentfredricOn 3 September 2017 at 12:16, James E Keenan via RT
Like the other Data::Dumper feature request you replied to with an - Yes, I considered that Maybe responses to bugs should be based on reading their content? -- KENTNL - https://metacpan.org/author/KENTNL |
From @iabynOn Sat, Sep 02, 2017 at 05:16:35PM -0700, James E Keenan via RT wrote:
As I just said in the other ticket, I think wishlist tickets should be -- |
From @xsawyerxOn 09/04/2017 11:34 AM, Dave Mitchell wrote:
I mostly agree. I think it's not unreasonable after a certain amount of time to revisit Having a large queue system is not in our favor because it makes it hard |
From @kentfredricBesides, here the delay has served its own purpose. It allowed me to get around to filing https://rt.perl.org/Public/Bug/Display.html?id=132027 , which should be implemented before this is even considered. I had meant to file it earlier, I just simply forgot/was distracted. Otherwise this feature just adds another potential formatting concern people *have* to make sure they've safe-guarded. |
From @demerphqIirc have implemented this feature and/or similar features in I do not think they are appropriate in Data::Dumper. DD is a special beast. It is bundled with perl, it has XS and perl A feature like this is something that will be of value to only a few, will As an author of two relatively widely used perl serialisation modules, one This type of feature for instance is likely to cause headaches to anyone So I would vote against this ticket, although I might support it in some Yves On 5 Dec 2015 03:25, "Kent Fredric" <perlbug-followup@perl.org> wrote:
|
From @kentfredricMuch of this is motivated by the facts that I've been using the competition for a long time, and there's only a handful of reasons why I'm using the competition. Data::Dumper is *mostly* fine, its just got some quirks that make it periodically impractical when dumping output *for humans* to read. If for example, I was the author of Data::Dumper::Concise, or Devel::Confess , it would be much preferable to just determine that the Data::Dumper that shipped with Perl had such useful functions for making output more readable, and the motivation to add a dependency on some other Dumper ( one that can't do deparse at that ) for this just wouldn't be worth it. Producing competition on CPAN is a fine philosophy, but software runs in cycles. You have a divergence phase where people fork off because they want something different, and then a waiting period while they discover all the things wrong with that approach. And then people find the best of what works and come together and re-centralise. We've spent years with this feature and others floating around on CPAN, its getting around about time for the best of those features to become available. I accept that perhaps, there are some issues with this feature being added to the DD code, but *shrug*. And I accept there are some people out there who won't have a use for it, and it won't work as a *serialization* strategy and DD will lose some fidelity when the feature is used. But that's why DD has tuneable features, and some of those features already lose fidelity and are unsuited for people using it as a serializer, But are perfectly fine for people who are just using DD for human readability. There's plenty of debugging code out there which uses DD which would love to just go "eval { DD->VERSION(3.1415) } ? $instance->CondenseRanges(1) ", because its much preferable than having your screen filled. And that's what Data::Dump is *good* at, just sometimes I want to see the source code of functions hiding in my data structures too, and I can't, I have to either have lots of cruft w/ source, or no cruft, and no source. And on top of that, I have to have useless conversations asking me why I need to depend on a 3rd party dumper library when there's one in core ... |
jkeenan
added
dist-Data-Dumper
Migrated from rt.perl.org#126812 (status was 'open')
Searchable as RT126812$
The text was updated successfully, but these errors were encountered: