MooseX::Extended versus the debugger

I've released MooseX::Extended 0.35 and it resolves a long-standing bug. If you tried to use multi subs, it would trigger this bug in Syntax::Keyword::MultiSub. To fix that, you had to manually patch the latter module:

--- old/lib/Syntax/Keyword/MultiSub.xs  2021-12-16 10:59:30 +0000
+++ new/lib/Syntax/Keyword/MultiSub.xs  2022-08-12 10:23:06 +0000
@@ -129,6 +129,7 @@
 redo:
     switch(o->op_type) {
       case OP_NEXTSTATE:
+      case OP_DBSTATE:
         o = o->op_next;
         goto redo;

Not good. However, Syntax::Keyword::MultiSub 0.03 has been released with that patch included, so that's a relief.

However, I was still struggling with switching WebService::OpenSky to MooseX::Extended but under the debugger, we have a serious problem.

MooseX::Extended Tutorial

There's been a lot of work on MooseX::Extended and now it comes with a fairly extensive tutorial.

The basics are pretty easy to learn, but it gives you a good amount of power. It also allows you to easily define custom versions so you can just slap use My::Custom::Moose; (or role) at the top or your code and it works just fine.

You can now disable just about any features in it you don't want. You can also include experimental features, such as multimethods (based on number of args) and async/await.

Check out the github repo if you'd like to contribute.

Introducing MooseX::Extended

MooseX::Extended is coming along well and is ready for testing. See Introducing MooseX::Extended for a decent introduction on how to make writing your Moose code safer and easier.

MooseX::Extreme Needs a New Name

On github, I've released MooseX::Extreme.

It's based on years of experience being the lead designer of the Corinna project and trying to figure out how we can get a version of Moose which is safer and easier to use, including removing a lot of boilerplate. This code:

package My::Class {
    use MooseX::Extreme;

    ... your code here
}

Is sort of the equivalent to:

package My::Class {
    use v5.20.0;
    use Moose;
    use MooseX::StrictConstructor;
    use feature qw(signatures postderef);
    no warnings qw(experimental::signatures experimental::postderef);
    use namespace::autoclean;
    use Carp;
    use mro 'c3';

    ... your code here

    __PACKAGE__->meta->make_immutable;
}

There's not need to end packages with a true value and MooseX::Extreme makes your class immutable for you.

But what's allowed in the constructor? I've regularly face the following problem:

package Some::Class;

use Moose;

has name     => (...);
has uuid     => (...);
has id       => (...);
has backlog  => (...);
has auth     => (...);
has username => (...);
has password => (...);
has cache    => (...);
has this     => (...);
has that     => (...);

Which of those should be passed to the constructor and which should not? Just because you can pass something to the constructor doesn't mean you should. Unfortunately, Moose defaults to "opt-out" rather than "opt-in" for constructor arguments. This makes it really easy to build objects, but means that you can pass things to the constructor and it won't always work the way you want it to.

There's an arcane init_arg => undef pair to pass to each to say "this cannot be set via the constructor," but many developers are either unaware of this is simply forget about it. MooseX::Extreme solves this by separating has into param (allowed in the constructor, but you can also use default or builder) and field, which is forbidden in the constructor. We can rewrite the above as this:

package Some::Class;

use MooseX::Extreme;

param name     => (...);
param backlog  => (...);
param auth     => (...);
param username => (...);
param password => (...);

field cache    => (...);
field this     => (...);
field that     => (...);
field uuid     => (...);
field id       => (...);

(Note: has is still available)

And now you can instantly see what is and is not intended to be allowed in the constructor.

It works with Perl versions from v5.20.0 onwards, has CI setup on github against all major Perl versions it supports, and even has some interesting fixes to make it work in the debugger.

In short, I'm trying to apply a list of safe (and conservative) defaults to Moose--I've deliberately omitted some features that would probably be overkill--and mostly just uses normal, sane modules.

It still needs more tests, so I won't release it right away, but it reduces boilerplate and and applies defaults that are generally popular. So what I should I rename it to before releasing to the CPAN?

The Tau Station Kickstarter has gone live! (Oops)

Not words you want to hear late at night before you're going to bed: "we accidentally launched our Kickstarter."

That's right, the Tau Station MMORPG Kickstarter is live and we didn't mean to. However, apparently Kickstarter doesn't allow you to "unlaunch" a campaign.

It may not have been our launch window, but we're owning this.

A man in a strange, orange hazmat suit stands there with a security droid floating over his right shoulder.

Share this!

Tau Station is the world's first Biblio-RPG. It's a massive, immersive, narrative sci-fi MMO. Missions in most games are things like "kill five rabid dogs and get a dagger." BORING. Our missions are rich, immersive, short stories where you control the outcome.

It's 400,000 plus lines of Perl, with a PostgreSQL backend.

About Ovid

user-pic Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you. And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/