Bug #132374 for Object-Pad: Cross-system testing

Sat Apr 18 12:45:51 2020 leonerd-cpan [...] leonerd.org.uk - Ticket created

Subject:

Cross-system testing

There's now a sufficient body of in-dist unit tests and CPAN-based cases (e.g. Tickit::Widget subclasses) that check classical perl subclasses of Object::Pad-based ones, or vice versa. We should consider making more cross-dist tests of other object systems; notably coming to mind are * Moo * Moose * Mojo::Base Of particular interest will be the fact that Moo/Moose and Object::Pad both want to consume a `BUILD` method. -- Paul Evans

Wed Apr 22 10:22:36 2020 haarg [...] haarg.org - Correspondence added

In Moo, the main considerations we needed to make for inheriting from other object systems (or hand rolled) were: FOREIGNBUILDARGS: Since Moo wants either a hashref or even a set of key+value pairs, this may not correspond to how the parent constructor wants to be called. Moo has FOREIGNBUILDARGS to adapt whatever is passed in before handing it off to the parent constructor. It does not take BUILDARGS into account. __no_BUILD__: Moo runs BUILD subs as part of construction. In addition to not wanting to run BUILD subs twice, Moo wants to run them after all other construction is done (populating attribute values from the constructor). The only way that makes sense to do this is by inhibiting the parent from calling BUILD itself. We created the __no_BUILD__ mechanism to do this. It is passed in the hashref or key+value pairs when calling the parent constructor, telling it not to call BUILD.

Wed Apr 22 10:22:37 2020 The RT System itself - Status changed from 'new' to 'open'

Sun Jun 21 10:53:40 2020 leonerd-cpan [...] leonerd.org.uk - Correspondence added

On Sat Apr 18 12:45:51 2020, PEVANS wrote: Show quoted text

> Of particular interest will be the fact that Moo/Moose and Object::Pad > both want to consume a `BUILD` method.

This is now of much less relevance. For performance reasons and internal restructuring to hopefully support roles in an upcoming version, Object::Pad's constructor no longer uses a method lookup in order to find BUILD blocks, so it won't get confused and run those intended for Moo/et.al. In addition, the next version to be released also fixes the side-effect that BUILD blocks are even stored as a named method, so Moo won't get get confused and see those. Theattached test passes on latest development version, which will become 0.31. HAARG: as the resident Moo expert, does that test look reasonable to you? I should probably write similar for Moose and Mojo::Base. -- Paul Evans

Subject:

08extends-Moo.t

#!/usr/bin/perl use strict; use warnings; use Test::More; BEGIN { plan skip_all => "Moo is not available" unless eval { require Moo }; } use Object::Pad; my $moocount; package Base::Class { use Moo; sub BUILD { my ( $self, $args ) = @_; Test::More::is_deeply( $args, { arg => "value" }, '@_ to Base::Class::BUILD' ); $moocount++; } } my $opcount; class Derived::Class extends Base::Class { has $slot; BUILD { my ( $args ) = @_; Test::More::is_deeply( $args, { arg => "value" }, '@_ to Derived::Class BUILD' ); $slot = 345; $opcount++; } method slot { $slot } } { my $obj = Derived::Class->new( arg => "value" ); is( $obj->slot, 345, 'slot value' ); } # Ensure the BUILD blocks don't collide with Moo's BUILD methods is( $moocount, 1, 'Moo Build method invoked only once' ); is( $opcount, 1, 'Object::Pad BUILD block invoked only once' ); done_testing;