- automatically ignore for Maybe types?  ugh, not as preferable as fixing
        spot-application as described below.

- register a shortcut, so traits => [ qw(UndefTolerant) ] will work

- doesn't work with sugar? see code below:

{
    package Class;
    use strict;
    use warnings;

    use Moose;
    use Sugar;

    field foo => (
        is => 'ro', isa => 'Str',
    );

    __PACKAGE__->meta->make_immutable;
}

use strict;
use warnings;

my $obj = Class->new(foo => undef);

https://rt.cpan.org/Ticket/Display.html?id=62287

15:47 <@ether> is anyone familiar with MooseX::UndefTolerant?
15:47 <@ether> I'm wondering why there is a constructor role as well as an attri
bute role
15:48 <@ether> is it just an optimization route if all attrs in a class are to h
ave this characteristic?
15:48 <@ether> (also, I'm having issues with getting it to work, but I can't be
more specific e.g. with a repro case yet)
16:08 < shadowpaste> "Ether" at 217.168.150.38 pasted "MooseX::UndefTolerant::At
tribute trait is not getting applied via sugar?" (58 lines) at http://paste.scsy
s.co.uk/53643
16:09 <@ether> I can't see what's going wrong here -- $attr->meta->does_role('Mo
oseX::SetOnce::Attribute') is true, but the method modifier is not being applied
 properly
16:09 <@ether> I can see the original Moose::Meta::Attribute::initialize_instanc
e_slot being called, but not the method mod
16:12 <@ether> I suspect this is another puzzle for doy :)
16:14 <@ether> (actually that paste example isn't quite right; the sugar class n
eeds to be in a separate file for the exports to work, apparently)
16:14 <@autarch> ether: I think the MX::UndefTolerant docs are wrong
16:14 <@autarch> you can't apply it to a single attribute if you immutablize the class
16:14 <@autarch> this seems like it should be fixable
16:15 <@ether> interesting, supposedly the latest release was supposed to fix that
16:16 <@ether> but indeed the distro doesn't have tests for immutability, and they break when I add it
16:16 <@ether> so one would need to method-modify the inlined version of initialize_instance_slot, presumably
16:16 <@autarch> basically, making an attr tolerant needs to change the metaclass _or_ we need to push slot initialization inling from Constructor back to the attribute class somehow
16:16 <@autarch> the latter might actually be a better idea
16:17 <@autarch> the slot init code in MMM::Constructor is quite terrifying
16:24 <@ether> eeck yeah that's not an exaggeration
16:28 <@ether> that's pretty verbose inlining code too
16:29 <@ether> instead of push @source, ... everywhere, one could just make a huge list of do{} clauses that return the correct substrs
16:29 <@ether> or join '', ...;
16:44 <@gphat> ether: http://github.com/gphat/moosex-undeftolerant
16:44 <@ether> thanks
16:44 <@gphat> np, gotta run for a bit (puter upgrade)
16:45 <@ether> currently it's no biggie to just apply the trait to the entire class, but there might be times when some attrs should be excluded, which is why I went for the spot application method first
16:45 <@rjbs> GvIMPORTED is fucking weird
16:47 <@ether> autarch didn't directly answer the original dilemma I had with this though -- why is the original Moose::Meta::Attribute::initialize_instance_slot being called, but not the method mod? that would suggest the role is not being applied properly.. how does this relate to immutability?



