Re: initializer

* Sean Allen s...@monkeysnatchbanana.com [2009-01-23T16:20:51] I'm reading the docs for initializer and am totally lost as to what it does, can someone explain? I keep reading the words but put together, just not getting it. Say you have an attribute like this: has attr = ( is

Re: Attribute initializers - incorrect documentation

* Hans Dieter Pearcey h...@pobox.com [2010-02-04T14:58:50] Triggers fire every time you set the value, including when it has a value already. Initializers don't. I think that's it. They were rjbs's baby originally, but I don't think he's actually using them. FWIW, I am. It is

feedback on MooseX::Worm

I am likely to release this code tomorrow: http://github.com/rjbs/moosex-worm It seems pretty reasonable to me, but if I'm doing something totally wrong, I'd love to find out now rather than later. -- rjbs

Throwable::X (like Throwable, with some X)

If you have been using Throwable and/or Throwable::Error for exceptions, you may be interested in looking at http://rjbs.manxome.org/rubric/entry/1860 in which I describe Throwable::X, a set of additional features for Throwable exceptions. -- rjbs

request for merge: $type_constraint-assert_coerce

I'd really like to do this a lot: sub whatever { my ($self, $input) = @_; $input = to_SomeType($input); ... } ...but this is not useful because to_SomeType returns false on failure to coerce. Similarly, $type-coerce($input) returns $input on failure to coerce. Some time ago I

request for merge: replace Test::Exception with Test::Fatal

Test::Exception (and its terrifying prereq, Sub::Uplevel) have caused us a few breaks-in-blead situations. This week, I released Test::Fatal, which provides a much simpler way to test for code that throws exceptions. It uses Try::Tiny and does not try to hide its calling stack frames. The

Re: request for merge: replace Test::Exception with Test::Fatal

* Karen Etheridge p...@froods.org [2010-10-24T15:55:52] On Sun, Oct 24, 2010 at 01:23:57PM -0400, Ricardo Signes wrote: The branch rfc/test-fatal completely removes any dependency on Test::Exception, and thus on Sub::Uplevel. I had originally planned to rewrite all the test files

Re: Newborn MooseX module up for adoption

* Tomas Doran bobtf...@bobtfish.net [2011-08-28T09:30:36] But if you really want to, there's a role for this already: http://search.cpan.org/~logie/MooseX-Role-MissingMethodUtils-0.02/lib/MooseX/Role/MissingMethodUtils.pm That role is beyond utterly totally broken. Among the many ways,

Re: Confused about Value and Item

* Ovid publiustemp-catal...@yahoo.com [2012-03-22T17:08:31] In trying to explain this, I got stuck on Item and Value. I have the following note about them: We discussed this briefly on Twitter. For the record, it was around https://twitter.com/ovidperl/status/182936878192934912 A word

the perl version support policy

A reading from Moose::Manual::Support: As of version 2.00, Moose officially supports being run on perl 5.8.3+. Our current policy is to support the earliest version of Perl shipped in the latest stable release of any major operating system (this tends to mean CentOS). We will provide at

changing default exception stringification

I just heard that there has been talk of changing the default stringification of Moose exceptions to emulate croak instead of confess. That is: don't include the complete stack trace, only one line. I am strongly opposed to this change, as I rely too much on getting full stack traces from my

Re: role stub workaround fails for parameterized roles

* John Macdonald [2018-04-09T15:05:02] > Is there a way to declare a stub method for parameterized roles? I think so. I feel like I've probably solved this, as I use parameterized roles often. Could you show us some *simple-as-possible* failing code, and I'll try to