We are doing parallel testing with -j4, so the hack of manually running each script with "perl" won't work. and I couldn't get --archive to produce any results for me. (Perhaps it's not compatible with parallel testing). We also use "done_testing()", so perhaps that it is part of the issue as well.
However, emitting JUnit works fine, I was just hoping to get TAP integration to work!
]]>5.20 is only 8 months away, so it seems very unlikely.
The current implementation is built on some pretty fragile techniques - these have been necessary to get it to work purely through modules, with no hooks added to Perl itself.
In particular, for implementing the mop's keywords (class
, method
, etc) it would be nice if the keyword API (introduced in Perl 5.14) played well with lexical subs (an experiment from Perl 5.18) so that the keywords could be used without polluting into the caller's namespace.
And the twigil implementation relies on the parsing of the Perl built-in special global $!
, looking for a bareword following it. It would be nice if there were proper support for parsing twigils in Perl core, even if that was just to ensure that $!foo
died with a sensible error message when used outside the scope of mop.
So there's still quite a bit to be done. Expecting it in Perl 5.20 is unrealistic. Personally I think 5.22 would be unlikely to; 5.24 or 5.26 are more likely. Hopefully the current github implementation could then be refactored into a CPAN "MOP::Compat" distribution, providing a mostly compatible version for Perl 5.16+. (Similar to how MRO::Compat backports much of the Perl 5.10 module "mro" to Perl 5.6+.)
]]>Is it possible to have something like
package Cat; class Food { has $!taste is ro; has $!brand is ro; has $!pounds is rw; }method Food::feed_lion { ... }
method Food::feed_cheetah { ... }
basically I want methods that I can define outside the class BLOCK (I dislike having one more level of indentation just for methods, and it is lazier to just s/^sub... /method .../
and wrap class around existing Moo* attribute declarations.
package Cat; sub _feed_lion { ... } sub _feed_cheetah { ... } class Food { has $!taste is ro; has $!brand is ro; has $!pounds is rw; method feed_lion { goto \&_feed_lion } method feed_cheetah { goto \&_feed_cheetah } }]]>
]]>
class Food;
has $!taste is ro;
has $!brand is ro;
has $!pounds is rw;
method feed_lion { ... }
method feed_cheetah { ... }
I like mop-redux and as one of "us common perl folks" and "regular users" I'd appreciate it a lot if we'd finally have SOMETHING released with core.
I'm just the vox populi nagging "are we there yet?".. :)
For example (pardon the pseudo-code) let's say that class Foo's constructor
accepts an optional object, bar.
In Moo+Types::Standard, one might do this
has 'bar' => (
is => 'ro',
isa => InstanceOf ['Bar'],
required => 0,
);
Let's posit that Bar's constructor returns undef upon failure. Old
school
Foo->new( bar => Bar->new );
will cause the validity check on bar to fail.
Will new school mop do the same? Or will it conclude that bar was
simply not specified because it was passed "undef", and continue?
The argument that currently undef means "not set" is not necessarily
the case. Here's a useful idiom, which allows for an optional
trailing argument whose value may be undef:
sub foo {
my ( $arg1, $arg2 ) = @_;
my $has_arg2 = @_ > 1;
}
undef can have a valid intrinsic meaning. It provides the ability to
specify a special state without having to define a special value (such
as NULL in C) which a) requires a common definition and acceptance by
the comminuity, and b) doesn't intersect the valid set of values for a
variable.
One of the aspects of Perl that I like is the unique position of undef
as a value. Take Lua, as a counter-example. It doesn't have a
separate sense of "existing but undefined", it has 'nil', which means
both non-existing and undefined, or whatever combination of those two
you prefer. There's no way to separate them out, and (in my
opinion/experience) leads to much less expressive code.
undef
work for has
exactly as it works for my
. Which is not how it works in Moo{se}, so in a sense we are returning the use of undef
back to its natural perlish state, just as Larry intended.]]>
My first impression: I mostly like how the code looks and that we get "safe" objects.
In a small example, the error messages I got were sensible and the script loaded fast.
I wonder if we could get the "colon-field notation" used by Object::InsideOut, e.g.
https://metacpan.org/module/Object::InsideOut#ATTRIBUTES
As for a more in-dept analysis it would be cool to read more posts of Perl gods regarding the mop.
]]>As for the new syntax, actually it is not anything terribly new, its been part of Perl 6 for a good ~10 years now
;)
]]>