This comment has been minimized.

@itcharlie would it be possible for you to rebase this PR against the latest master (and possibly squash some of those merge commits down)? I think some of the performance differences can be improved. It would be a shame for this work not to be merged, as Moo is preferred over Mouse these days.

This comment has been minimized.

+1 for this changeset. Xslate is the only thing I routinely use that is dependent on Mouse and it would be extremely disappointing to see this work not accepted, especially given that the benchmark differences are pretty negligible.

I can only get a 1% benchmark difference because almost all the work in almost all the benchmarks is being done by ->render's XS code. Well, except for the poor-env test where Moo appears to be loading slightly faster but I'm not sure that's really a significant difference either.

The getopt stuff in Runner needs tweaking as well but that didn't show up at the top of my profile (MooX::Options would maybe solve this, or borrowing part of its implementation)

This comment has been minimized.

If somebody can propose a benchmark that shows a more-than-1% slowdown in a way I can actually proile, I wouldn't mind poking this with a stick. The Symbol thing was basically the only thing I managed to get a handle on from the benchmark scripts. It's friday evening though, so I may just be being stupid.

This comment has been minimized.

-1 with this. Just because people can't stand to add one standalone module to their module list, they are willing to impose several new modules to others. @gfx already expressed that he was not willing to switch to Moo but would consider plain objects. Text::Xslate works fine with Mouse, and it doesn't need to be "fixed" with Moo.

Personally, I don't want to add Moo and its dependencies to my module set. Already did, and it cost me a week to revert because people knew better than me how I should handle warnings. Not anymore!

This comment has been minimized.

@GeJ If you don't want to write warning clean code, Moo 2.0 in March no longer fatalises warnings by default. If you'd like to learn how, strictures 2 now only fatalises warnings we can be reasonably sure won't cause forward compatibility issues.

Also, if you have a pre-2.0 Moo you can easily do -

use Moo;
use warnings NONFATAL => 'all';

or use Moo::Lax or ...

Plenty of options other than reversion and they're all basically a single perl -pi -e away :)

This comment has been minimized.

@shadowcat-mst I perfectly know that. That's the quick fix I implemented two years ago when I was asked to leave a Sunday family gathering by a pissed off boss who got harassed by an angry client who was asking why none of his orders were processed in a timely fashion.

When I went to the office on that day I realized that someone, somewhere thought that appending an undefined value to a string was such an offense to the programming Gods that it should warrant killing any piece of code that would attempt to do so. And that's my problem with Moo : I don't like such clear POLA violations and I can't trust people who commit them. And rather than doing a rollback, Moo users had to use a workaround for roughly a year.

Also, and aside any personal opinion I may have on Moo, the root of this PR is just for convenience. There is no technical merit in this. s/Mouse/Moo/g everywhere in the code is not enough, it is slower than the original. Looking back at the PR, it has been suggested to add even more extra modules to catch up, or worse : drop the Moo API and directly tap into the guts of the object to speed up things. Wow!

I will repeat myself : just because people don't want to add one standalone module, they are willing to impose their convoluted solution to others. Mouse works just fine. It may not have all the bells and whistles of Moose or Moo, but it is in my opinion the perfect example of a much simple solution that fits the needs of a given problem. If memory serves, when I removed every reference to Moo in my code, there were no Moo-only feature I used that couldn't be replaced by either a Mouse extension or half a dozen lines of code.

Finally, a careful reader might remember that a respected member of the Perl community qualified Mouse as "amazing code", adding "If you're going to use Mouse, use Mouse." So, can we please leave it like that and stop trying to fix a problem that doesn't exist.

Edit: added a few edits this and there to fix a few mistakes. Please forgive my possibly awful English as it is not my native language.

This comment has been minimized.

And that's my problem with Moo : I don't like such clear POLA violations and I can't trust people who commit them.

It was already clearly documented. I'm sorry you missed it.

And rather than doing a rollback, Moo users had to use a workaround for roughly a year.

The first ever release of Moo fatalized warnings. The delay was to try and minimise the damage to downstream users who -liked- them and regarded them as an important part of their code's integrity. Your "rollback" would've been their "sudden backcompat breakage", and that wasn't acceptable to us.

Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.