DEV Community: kobaken

Released Test2::Plugin::SubtestFilter which filters tests by subtest name.

kobaken — Mon, 20 Oct 2025 23:39:16 +0000

I have released Test2::Plugin::SubtestFilter for Perl tests, which allows filtering test targets by subtest name, similar to --testNamePattern in jest and vitest. I think it is useful when you want to run only specific tests.

# t/test.t
use Test2::V0;
use Test2::Plugin::SubtestFilter;

subtest 'foo' => sub {
    subtest 'nested foo1' => sub { ok 1 };
    subtest 'nested foo2' => sub { ok 1 };
};

subtest 'baz' => sub {
    ok 1;
};

done_testing;

# Run tests matching `foo1`
❯ SUBTEST_FILTER=foo1 prove -lvr t/test.t
t/test.t ..
# Seeded srand with seed '20251020' from local date.
ok 1 - foo {
    ok 1 - nested foo1 {
        ok 1
        1..1
    }
    ok 2 - nested foo2 # skip
    1..2
}
ok 2 - baz # skip
1..2
ok
All tests successful.
Files=1, Tests=2,  0 wallclock secs ( 0.00 usr  0.00 sys +  0.04 cusr  0.00 csys =  0.04 CPU)
Result: PASS

Released an Inertia.js Adapter for Mojolicious

kobaken — Mon, 15 Sep 2025 07:18:19 +0000

Hi, I'm kobaken.

I've released an adapter for using Inertia.js with Mojolicious, a Perl backend framework. Inertia.js is a bridging library that connects backend frameworks with components written in React, Vue, and other frameworks.

https://metacpan.org/pod/Mojolicious::Plugin::Inertia

What is Inertia.js?

Inertia.js is a framework that connects backend frameworks with React or Vue components. It allows you to use modern frontend components while maintaining a traditional backend approach.

I figure this is an approach that fits well when you have substantial assets on the backend side, but replacing everything would be too costly, and you want to start by improving the client-side experience.

When using components written in React, Vue, etc. with backend frameworks like Mojolicious, I believe there are two approaches. One is to mix JavaScript code into the backend framework's proprietary template engine. The other is to call backend APIs and handle rendering with CSR or SSR. Both approaches result in more complex architecture compared to the days when you could simply select a template on the backend and pass values to it.

With Inertia.js, you can use React and other components while maintaining the good old way of writing code. Specifically, it works as follows: by writing $c->inertia(COMPONENT, PROPS) on the backend side, Inertia.js will connect with the component.

Inertia.js is the simple protocol

Another point I found appealing is that the protocol for this connection is simple. It's remarkably simple.

For example, if you write it like this...

$c->inertia('Index', {
   user => { name => 'Mojolicious' }
})

It returns this JSON:

{
   "component": "Index",
   "props": { "user": { "name": "Mojolicious" } },
   "url": "/",
   "version": "c53bc3824540ea95b1e9b495c7a01a9d"
}

So straightforward!

In fact, looking at Inertia.js's protocol, it's content you can finish reading in about 10 minutes, and Mojo's plugin is less than 100 lines, so I think it would be easy to port to other Perl frameworks.

Recently, in another project, I made React Server Components usable with Hono, but understanding that in 10 minutes is difficult for me 😅 Since Inertia.js becomes CSR, I think React Server Components is better if you're looking for user experience and SEO, but I believe there are situations where Inertia.js is sufficient.

https://zenn.dev/kfly8/articles/hono-meets-vite-rsc (Japanese)

Please give it a try if you'd like!

Type library kura meets built-in class.

kobaken — Mon, 25 Nov 2024 07:31:46 +0000

https://metacpan.org/pod/kura

The type library kura now possible to use the Perl with built-in class. This allows you to gather objects and types.

use v5.40;
use experimental 'class';

class Fruit {
    use Exporter 'import';
    use Types::Common -types;

    # kura meets built-in class!
    use kura Name => StrLength[1, 255];

    field $name :param :reader;

    ADJUST {
        Name->assert_valid($name);
    }
}

my $fruit = Fruit->new(name => ''); # Error!

This is a unique feature of kura, that isn't possible with Type::Library.

Feel free to give it a try!

This article is for Japanese Perl Advent Calendar 2024

Released Result::Simple - a dead simple perl-ish Result like F#, Rust, Go

kobaken — Sat, 23 Nov 2024 22:43:37 +0000

https://metacpan.org/pod/Result::Simple

Result::Simple is a dead simple Perl-ish Result.

Result represents a function's return value as success or failure, enabling safer error handling and more effective control flow management. This pattern is used in other languages such as F#, Rust, and Go.

In Perl, this pattern is also useful, and this module provides a simple way to use it. This module does not wrap a return value in an object. Just return a tuple like ($data, undef) or (undef, $err). For example, take a look at a implement of Ok function:

# When the function is successful, it should return this.
sub Ok {
    if (CHECK_ENABLED) {
        croak "`Ok` must be called in list context" unless wantarray;
        croak "`Ok` does not allow multiple arguments" if @_ > 1;
        croak "`Ok` does not allow no arguments" if @_ == 0;
    }
    ($_[0], undef)
}

It is a dead simple!

However, it decreases the bugs. For instance, if you forget to handle $err, it can be detected by Perl::Critic::Policy::Variables::ProhibitUnusedVarsStricter. This is one of effectiveness of Result pattern!

Feel free to give it a try!

——-

This blog is for Japanese perl advent calendar 2024.

Released 'kura' - Store constraints for Data::Checks, Type::Tiny, Moose and more.

kobaken — Sun, 18 Aug 2024 14:15:39 +0000

Perl offers several libraries for managing type constraints, such as Data::Checks, Type::Tiny, and Moose. In large projects, you might encounter a mix of different type constraints, reflecting the codebase’s evolution over time. Furthermore, recent Perl versions have introduced projects like Corinna, which focuses on class features, and Oshun, which deals with value checking (with Data::Checks being a prototype from this project). Given these developments, I believed it would be useful to manage multiple type constraints through a unified interface, simplifying the process of staying up-to-date with Perl’s advancements.

To address this, I have released Kura, a tool designed to store and retrieve various type constraints from libraries like Data::Checks, Type::Tiny, and Moose in one central location. “Kura” is the Japanese word for a traditional storehouse.

Data::Checks -----------------> +--------+
                                |        |
Type::Tiny -------------------> |        |
                                |  Kura  | ---> Named Value Constraints!
Moose::Meta::TypeConstraint --> |        |
                                |        |
YourFavoriteConstraint -------> +--------+

The following code is synopsis:

package MyFoo {
    use Data::Checks qw(StrEq);
    use kura Foo => StrEq('foo');
}

package MyBar {
    use Types::Standard -types;
    use kura Bar => Str & sub { $_[0] eq 'bar' };
}

package MyBaz {
    use Moose::Util::TypeConstraints;
    use kura Baz => subtype as 'Str' => where { $_[0] eq 'baz' };
}

package MyQux {
    use kura Qux => sub { $_[0] eq 'qux' };
}

use MyFoo qw(Foo);
use MyBar qw(Bar);
use MyBaz qw(Baz);
use MyQux qw(Qux); # CodeRef converted to Type::Tiny

ok  Foo->check('foo') && !Foo->check('bar') && !Foo->check('baz') && !Foo->check('qux');
ok !Bar->check('foo') &&  Bar->check('bar') && !Bar->check('baz') && !Bar->check('qux');
ok !Baz->check('foo') && !Baz->check('bar') &&  Baz->check('baz') && !Baz->check('qux');
ok !Qux->check('foo') && !Qux->check('bar') && !Qux->check('baz') &&  Qux->check('qux');

The following code shows how Kura can be used. If you manually replace use kura with type, it should read similarly to type declarations in statically typed languages😁

package MyFoo {
   use Types::Standard -types;

   use kura Name  => Str & sub { qr/^[A-Z][a-z]+$/ };
   use kura Level => Int & sub { $_[0] >= 1 && $_[0] <= 100 };

   use kura Charactor => Dict[
      name  => Name,
      level => Level,
   ];
}

package main;
use MyFoo qw(Charactor);

Charactor->check({ name => 'Alice', level => 50 });

Happy Hacking!

https://metacpan.org/release/KFLY/kura-0.01/view/lib/kura.pm

Released Syntax::Keyword::Assert

kobaken — Wed, 14 Aug 2024 15:20:27 +0000

https://metacpan.org/pod/Syntax::Keyword::Assert

The assert { ... } syntax allows you to create assertions based on the evaluation of a block. One of the key advantages of using a keyword plugin like this is that it doesn’t degrade performance in production environments where assertions might be unnecessary. This is similar to how assertions work in compiled languages.

Here’s a simple example:

use Syntax::Keyword::Assert;

sub hello($name) {
    assert { defined $name };
    say "Hello, $name!";
}

hello("Alice"); # => Hello, Alice!
hello();        # => Dies when STRICT mode is enabled

Keyword plugins hook into Perl’s parser to extend its syntax. Paul Evans, a Perl developer, has been making extensive use of this feature. Instead of directly modifying Perl’s core, he prototypes new features using keyword plugins, gathers feedback from the community, and then works towards incorporating them into Perl itself. Recent syntax extensions like try/catch, defer, and class are results of this approach. (a remarkable achievement!).

Examples of Modules Using Keyword Plugins:

How Do Keyword Plugins Work?

Here’s a general idea of how keyword plugins function:

The parser detects the specified keyword (in this case, assert).
It inserts the desired OP tree (similar to an abstract syntax tree) around the keyword. That's it!

For instance, in the case of Syntax::Keyword::Assert, the code assert { defined $name } gets transformed into an OP tree equivalent to the following:

# When STRICT mode is enabled
croak 'Assertion failed' unless do { defined $name };

# When STRICT mode is disabled, do nothing.

For those interested in the source code, here’s how it works:

Pretty interesting, right?

Development Notes

As a side note, I wasn’t initially familiar with constructing OP trees, so I’ll document my process here for future reference.

Here’s the general workflow I followed:

First, write the content you want to replace with a keyword in pure Perl. For this example, it’s croak ... unless BLOCK.
Use tools like B::Terse and B::Debug to understand the resulting OP tree.
Verify that the OP tree you’ve written matches the one from the original code.
Additionally, check the output with B::Deparse to ensure it matches your expectations.
Iterate until you get the desired results.

I also found the following resources helpful:

The source code of other modules that use keyword plugins.
- Since this syntax involves KEYWORD BLOCK, it’s essentially the same as Syntax::Keyword::Defer, apart from the OP tree construction.
Reading perlapi and examining core Perl files like op.c and opnames.h made it easier to understand OP tree construction.
- If you’re unclear on terms like SV or OP, I recommend reading this article by tokuhirom: https://xsubtut.github.io/ (jp).
I also frequently used Yet Another CPAN Grep to search for relevant code.
- https://grep.cpanauthors.org/search

That’s all for now!

Happy Hacking!

Benchmarked new perl class feature with many class builders[2025-10-30 updated]

kobaken — Sat, 12 Aug 2023 07:57:04 +0000

[Updated]

(2025-10-30 0:13 JST) update to v5.42 benchmarked & optimize Classical Core Class Implementations #10 (Thanks @bodo-hugo-barwich )
(2024-06-10 11:13 JST) update to v5.40 benchmarked result GitHub - kfly8/bench-perl-class-builder at v5.40
(2023-08-22 21:30 JST) Added the following pull requests, then benchmarked. Thanks @bbrtj
- Add XS variants for Moose and Moo
(2023-08-22 15:30 JST) Added the following pull requests, then benchmarked. Thanks @bbrtj
- Add immutable for Moose class #1
- Add two extra fields for each class #2

What's this?

In Perl 5.38, the class feature was integrated into the core, so I compared it with many class builders. Ovid, who is main designer of new class feature, blogged the follwing thing:

Note that it’s not taking anything away from Perl; it’s adding a core object system for better memory consumption, performance, and elegance.
( https://ovid.github.io/articles/corinna-in-the-perl-core.html )

The summary is as follows. Note that this class syntax is still experimental, so results may vary depending on future development.

As of v5.38 [https://github.com/kfly8/bench-perl-class-builder/tree/v5.38:title]
- This new class syntax was the most memory efficient, and the performance of constructors and object accessors was comparable to that of the array references with bles. (Performance was better than bless with the most used hash reference.)
For v5.40 [https://github.com/kfly8/bench-perl-class-builder/tree/v5.40:title]
- This new class syntax was the most memory efficient.
- The constructor had performance comparable to that of the array reference blessed.
- The object accessors performed as well as a hash reference without.

Execution Environment

* Operating System:
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.1
-- https://github.com/kfly8/bench-perl-class-builder/blob/1549f173d9b93c252d73019079b0feb7620bfa84/.github/workflows/benchmark-debian-trixie.yml#L23-L28

Benchmark memory size

Size	Compare	Title
163.1 KB	--	`class feature (perl: 5.042000)`
257.9 KB	58.10%	`bless arrayref`
265.7 KB	62.90%	`Object::Pad@0.821`
359.5 KB	120.40%	`Moose@2.4000 (XSAccessor)`
359.5 KB	120.40%	`Moo@2.005005 (XSConstructor + XSAccessor)`
359.5 KB	120.40%	`Class::Tiny@1.008`
359.5 KB	120.40%	`Class::Accessor::Lite@0.08`
359.5 KB	120.40%	`Moose@2.4000`
359.5 KB	120.40%	`Object::Tiny@1.09`
359.5 KB	120.40%	`Moo@2.005005`
359.5 KB	120.40%	`Mouse@v2.5.11`
359.5 KB	120.40%	`bless hashref`

This result were calculated using bench-size.pl.

Benchmark object constructors

Rate	Compare	Title
301/s	-65%	`Class::Tiny@1.008`
431/s	-50%	`Moose@2.4000 (XSAccessor)`
432/s	-50%	`Moose@2.4000`
550/s	-36%	`Moo@2.005005`
550/s	-36%	`Moo@2.005005 (XSConstructor + XSAccessor)`
627/s	-27%	`Mouse@v2.5.11`
684/s	-20%	`Object::Pad@0.821`
760/s	-12%	`bless arrayref`
861/s	--	`class feature (perl: 5.042000)`
1028/s	19%	`bless hashref`
1046/s	22%	`Class::Accessor::Lite@0.08`
1090/s	27%	`Object::Tiny@1.09`

This result were calculated using bench-new.pl.

Benchmark access to object fields

Rate	Compare	Title
24093/s	-26%	`Object::Pad@0.821`
29538/s	-9%	`Class::Accessor::Lite@0.08`
31210/s	-4%	`Moose@2.4000`
32581/s	--	`class feature (perl: 5.042000)`
33998/s	4%	`Class::Tiny@1.008`
34600/s	6%	`Moo@2.005005`
41155/s	26%	`bless hashref`
42708/s	31%	`bless arrayref`
44246/s	36%	`Object::Tiny@1.09`
55137/s	69%	`Moose@2.4000 (XSAccessor)`
59077/s	81%	`Mouse@v2.5.11`
71739/s	120%	`Moo@2.005005 (XSConstructor + XSAccessor)`

This result were calculated using bench-field.pl.

Repository

https://github.com/kfly8/bench-perl-class-builder

Released types for subroutines

kobaken — Sat, 18 Sep 2021 14:14:25 +0000

It is useful to have a subroutine type, so I made one.

use Types::Sub -types;
use Types::Standard -types;

my $Sub = Sub[
    args    => [Int, Int],
    returns => Int,
];

warn $Sub->validate(sub {})
# =>
# Reference sub { "DUMMY" } did not pass type constraint "Sub[sub(Int, Int) => Int]"
#    Reason : invalid parameters: invalid args length. got: 0, expected: 2
#    Expected : sub(Int, Int) => Int
#    Got      : sub(*) => *

If you can find the meta-information from the subroutine, the test will pass as follows.

use Types::Sub -types;
use Types::Standard -types;

my $Sub = Sub[
    args => [Int, Int],
];

use Function::Parameters; 
fun add(Int $a, Int $b) { return $a + $b }
ok $Sub->check(\&add);

use Sub::WrapInType qw(wrap_sub);
ok $Sub->check(wrap_sub([Int,Int] => Int, sub {}));

use Sub::WrapInType::Attribute;
sub add2 :WrapSub([Int,Int] => Int) {
    my ($a, $b) = @_;
    return $a + $b
}
ok $Sub->check(\&add2);

sub add3 {}
my $meta = Sub::Meta->new(
    args    => [Int, Int],
    returns => Int,
);
Sub::Meta::Library->register(\&add3, $meta);
ok $Sub->check(\&add3);

Internally, Sub[...] coerces subroutines into Sub::Meta and compares Sub::Meta against each other.

Give it a try!
https://metacpan.org/release/KFLY/Sub-Meta-0.14/view/lib/Types/Sub.pm

Tools for learning Perl context

kobaken — Mon, 10 May 2021 12:41:40 +0000

There are times when I am confused by the context of Perl. I wrote a tool to reduce this confusion.

kfly8 / p5-Contextual-Diag

diagnose contexts

Usage

If you plug in the contextual_diag subroutine where you want to know Perl context, it will alert you to the context.

The following code explores the context when evaluating the value of a hash reference:

use Contextual::Diag;

# Here...
my $a = { key => 'value' };

# Do this...
my $a = { key => contextual_diag 'value' };

# Then this happens!
# => wanted LIST context

Inside Contextual::Diag

In Contextual::Diag, the first step is to use wantarray to separate contexts into SCALAR, LIST, and VOID. Then, in the case of SCALAR context, the return value is wrapped in an object, and overload is used to hook into string evaluation, numeric evaluation, and array dereferencing. Only in the case of object reference, overload is not enough to hook, so AUTOLOAD is used. I got this idea from Professor Damian's Contextual::Return.

List of diagnoses

Contextual::Diag has a total of 11 different diagnoses:

1. SCALAR context
   - CASE: Scalar value
      - BOOL e.g. `if ($value)`
      - NUM e.g. `$value + 1`
      - STR e.g. `$value . "hello"`
   - CASE:  Scalar reference
      - SCALARREF e.g. `$$value`
      - ARRAYREF e.g. `$value->[0]`
      - HASHREF e.g. `$value->{key}`
      - CODEREF e.g. `$value->()`
      - GLOBREF e.g. `*{$value}->{CODE}`
      - OBJREF e.g. `$value->hello()`
2. LIST context
3. VOID context

Conclusion

I wrote Contextual::Diag to make it easier to understand Perl context.

You can use it if you like!

Released Sub::Meta that handles function meta information in Perl 5

kobaken — Tue, 09 Jul 2019 14:05:28 +0000

Sub::Meta - handle subroutine meta information - metacpan.org

Sub::Meta is a module to handle meta information such as subroutine names and subroutine input/output.
There are similar modules such as Sub::Identify,Sub::Util and Sub::Info, but writeSub::Meta because it can not handle the meta information of the input/output of the subroutine.

The basic usage is as follows.
You can get meta information based on the code reference:

use Sub::Meta;

sub hello($) :mehtod { }
my $meta = Sub::Meta->new(sub => \&hello);
$meta->subname;     # hello
$meta->sub;         # \&hello
$meta->subname;     # hello
$meta->fullname;    # main::hello
$meta->stashname;   # main
$meta->file;        # path/to/file.pl
$meta->line;        # 5
$meta->is_constant; # !!0
$meta->prototype;   # $
$meta->attribute;   # ['method']

You can also handle meta information without passing a code reference:

my $meta = Sub::Meta->new(subname => 'foo');
$meta->subname; # foo

Function input/output meta information can be added:

# INPUT
my $parameters = Sub::Meta::Parameters->new(
  args => [
    { name => '$a', type => 'Int' },
    { name => '$b', type => 'Int'},
  ],
  nshift => 1,
);

$meta->set_parameters($paramters);
$meta->parameters->args;
# [
# Sub::Meta::Param->new({ name => '$a', type => 'Int' }),
# Sub::Meta::Param->new({ name => '$b', type => 'Int' })
# ]

# OUTPUT
my $returns = Sub::Meta::Returns->new(
  scalar => 'Int',
  list   => 'Int',
);
$meta->set_returns($returns);
$meta->returns->scalar; # 'Int'

Let's dig into the motivations for working with function input and output meta information.

Perl5 has many modules that validate function input, such as Params::Validate,Data::Validator, Smart::Args,Function::Parameters, Type::Params, etc.

Each module has different usability, I thought it was somewhat stressful.
Also, I wanted to do Static analysis because I was annotating the types.

Therefore, I thought that if there is an object that handles meta information of the input of the function, it will be easier to handle in a unified I/F.

The same is true for function output.

Also, when trying to express a Java-like Interface in Perl5 such as Function::Interface, it is useful if the input/output of functions is easy to handle.

The current F::I is sticky in the Function::Parameters and Function::Return implementations, and I thought that it could not handle many applications and lacked flexibility.

That's why I created Sub::Meta that can handle meta information including function input and output. I'm glad to try it if it is good! That's all!

Release: Function::Interface

kobaken — Thu, 21 Mar 2019 11:46:43 +0000

I'm developing Function::Interface, this module provides a typed interface like Java interface.
At compile time, check if the abstract functions are implemented.

You can see the demo in the following capture:

USAGE

Declare typed interface package IFoo:

package IFoo {
    use Function::Interface;
    use Types::Standard -types;

    fun hello(Str $msg) :Return(Str);

    fun add(Int $a, Int $b) :Return(Int);
}

Implements the interface package IFoo:

package Foo {
    use Function::Interface::Impl qw(IFoo);
    use Types::Standard -types;

    fun hello(Str $msg) :Return(Str) {
        return "HELLO $msg";
    }

    fun add(Int $a, Int $b) :Return(Int) {
        return $a + $b;
    }
}

It is good not to depend on the implementation:

package FooService {
    use Function::Interface::Types qw(ImplOf);
    use Function::Parameters;
    use Function::Return;
    use Mouse;

    use aliased 'IFoo';

    fun greet(ImplOf[IFoo] $foo) :Return() {
        print $foo->hello;
        return;
    }
}

my $foo_service = FooService->new;
my $foo = Foo->new; # implements of IFoo

$foo_service->greet($foo);

How it works

To explain briefly

The keywords fun andmethod for declaring abstract functions are implemented in Keyword::Simple and PPR. B::Deparse shows that it stores meta information of abstract functions.
In order to check whether the interface is correctly implemented, the stored interface meta information is compared with the implementation meta information that can be obtained using Function::Parameters and Function::Return.

Finally

Have you ever experienced the software becoming bigger and less maintenance? In such a case, I think it is important to divide the code, make it easy to change, and make code easier to read.

In order to divide the code, I think the interface is useful.
Please try it!!

Thanks.