Front page | perl.perl5.porters |
Postings from December 2015
On 19 December 2015 at 03:09, David Golden <xdg@xdg.me> wrote: > On Fri, Dec 18, 2015 at 6:39 PM, demerphq <demerphq@gmail.com> wrote: >> >> > Until there is a compelling case for why it should go into core, I >> > oppose >> > adding it. >> >> I think that is sad. >> >> ... >> I think that is entirely the wrong approach to problems like this. > > > Perhaps I can restate it in terms you won't find sad. > > I don't think we should ever approach core additions with an argument like > this: "I have great idea X, anyone object?" Sure. Fair enough. But I don't think we should ever dismiss feature additions to core modules with an argument like this: "Why does this behavior need to be in core when there are already alternatives on CPAN?" I think if you are going to oppose you need to come up with constructive basis to reject the patch that does not involve simply referencing the existence of a different module on CPAN. First of all, I think that a poster like Chad, who actually has a patch in hand deserves better quality feedback than "whats wrong with the version on CPAN". If they can do the work to propose a patch, then you can do the work to come up with a better objection. Second I think the general idea of "there is an alternative on CPAN that does that" is fundamentally broken. Consider the implications; we have what, a small handful of Exporter like modules on CPAN. If someone is working on a large application (like I do at $work), odds are that they are going to end up loading many if not all of them. A developer working on a code base like that is in worst case going to have to learn the subtleties of all of them. Maybe there is a bug in one of them, maybe someone gets confused and uses the interface of one for configuring another, etc etc. The point being that having multiple modules that do almost the same thing with different API's increases cognitive load on the developer, increases the chances of bugs, slows down process startups by increasing the number of modules loaded, and uses more memory. > I think additions should at least be approached like this: "I have great > idea X. I think it should go into core because Y and Z. Do people agree?" I think that a sure sign of a missing feature in core is multiple modules that do the same thing as a core module, but add a few features. I think that is prime grade evidence that it should have been in the core in the first place. Less for people to learn, less dependencies to load, etc. > Even better: "I have great idea X. The benefits are Y and Z. The downsides > are P and Q. On balance, I think that it would be a good addition to core. > Do people agree? Have I missed anything?" I don't disagree. But at the same time I think sometimes that certain features are so obviously useful that we shouldn't have to pass a gauntlet every time. (Especially not for a 6 line patch.) And I feel this is one of those cases. And I feel that the fact there are multiple modules on CPAN that add that feature should be considered conclusive evidence that there is a demand for the feature that core is not filling. > > This doesn't mean we shouldn't ever add to core. It means that we should > have a case that is better than "no one said no". Sure. But again, the case against should be better than "there is a module on CPAN that does the same thing already". I have seen some comments in this thread that try to a build an argument about what problems might come up. I dont know that I agree with them, but those objections are quite different to "there is a module on CPAN that does the same thing already". Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next