develooper Front page | perl.perl5.porters | Postings from December 2015

Re: Proposal: Add {-as => 'new_name'} feature to

Thread Previous | Thread Next
December 20, 2015 00:00
Re: Proposal: Add {-as => 'new_name'} feature to
Message ID:
On 19 December 2015 at 03:09, David Golden <> wrote:
> On Fri, Dec 18, 2015 at 6:39 PM, demerphq <> 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".


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