Jesse Luehrs (d...@tozt.net)

MooseX::AttributeTree seems to be exactly what you're looking for here.
It also handles a lot of other edge cases that your basic implementation
doesn't, such as inherited attributes.

> 2) If not, is the implementation of the trait correct? What bothers me
> most is extending the private _inline_get sub, which seems wrong
> (although MooseX::Worm does that too).

But your implementation looks fine, Moose extensions are intended to be
able to override any part of the implementation of things. Privacy
really just indicates which parts of the API are useful for people to
use for introspection (i.e. there's no reason for anyone to actually
call _inline_get themselves, which is why it's private).

-doy

I'm not sure what problem you're having, since you didn't post the
error message, but you probably need the attribute definition to happen
after the types are defined... pretty sure this would assume you have a
class named 'MaybeDateTime'.

> # this generates "Attempt to free unreferenced scalar" error!
> #has date => ( is => 'rw', isa => 'Undef | DateTime', coerce => 1 );

If you could turn this issue into an actual failing test, that would be
really helpful.

> subtype 'DateTime' => as 'Object' => where { $_->isa('DateTime') };

Also, this is equivalent to "class_type 'DateTime'".

> subtype 'MaybeDateTime'
>     => as 'Maybe[Object]'
> => where { $_->isa('DateTime') or not defined $_ };
>
> coerce 'MaybeDateTime'
>     => from 'DateTime'
>     => via { return $_ };
>
> coerce 'MaybeDateTime'
>     => from 'Str'
>     => via {
> print "### calling Str->MaybeDateTime coercion\n";
>         # check for retarded mysql 4.x null times
>         return if $_ eq '0000-00-00 00:00:00';
> return DateTime::Format::MySQL->parse_datetime($_);
>     };
>
> coerce 'DateTime'
>     => from 'Str'
>     => via {
> print "### coercing Str $_ into DateTime\n";
> return DateTime::Format::MySQL->parse_datetime($_);
>     };
>
> 1;

-doy

To clarify, if you want Moose features during object construction
(rather than just handling attributes and such), you should use
$meta->name->new, not $meta->new_object.

-doy

Actually, I've thought some more about this, and disregard this last
paragraph.

> Another possible solution to this problem would be to force all classes
> which get incidentally initialized like this to have CMOP metaclasses,
> but this tends to break in complicated inheritance situations - for
> instance, Moose::init_meta won't reinitialize a class with a CMOP
> metaclass to have a Moose metaclass, it just throws an error (probably
> since upgrading the metaclass in a safe way that preserves things like
> existing attributes and such would be a pain). Also, in some situations,
> the temporary metaclass needs to be a Moose::Meta::Class -
> _fix_metaclass_incompatibility for instance doesn't exist in CMOP, so in
> a Moose - non-Moose - Moose inheritance setup, the non-Moose class needs
> to get a Moose metaclass to run _fix_metaclass_incompatibility on to see
> if it is going to need fixing (this isn't a big deal, since metaclass
> compatibility means that it needs to have a Moose metaclass anyway, but
> still something to watch out for).

This here is the actual correct solution. The issues I brought up here
are all really just bugs in our metaclass compat code, that really
should be fixed. I'll see about having another shot at this sometime
later this week.

> So... any thoughts?
>
> -doy

-doy

So, after a discussion with mst in #moose, he pointed out that
initializing a non-Moose class with a Moose metaclass is a bug, and we
really shouldn't be doing it. This occurs quite a bit in code within
CMOP and Moose, which does things like:

  for my $class ($self->linearized_isa) {
      my $meta = $self->initialize($class);
      ...
  }

and similarly with $self->superclasses, etc. When called on a Moose
class, this will initialize any non-Moose ancestors with a metaclass of
Moose::Meta::Class, which isn't really correct.

I looked into this, and it seems like the only way to accomplish this
safely is to not cache metaclasses which aren't explicitly initialized.
I've implemented this on the topic/nonmoose_gets_cmop_meta branches of
CMOP and Moose (the name is from an earlier attempt which used a
different strategy). It seems to work properly, and fixes the issues
that I've been able to find, but I was wondering if people think this is
a sane thing to want to do, or if this is going to cause other issues
down the road.

Another possible solution to this problem would be to force all classes
which get incidentally initialized like this to have CMOP metaclasses,
but this tends to break in complicated inheritance situations - for
instance, Moose::init_meta won't reinitialize a class with a CMOP
metaclass to have a Moose metaclass, it just throws an error (probably
since upgrading the metaclass in a safe way that preserves things like
existing attributes and such would be a pain). Also, in some situations,
the temporary metaclass needs to be a Moose::Meta::Class -
_fix_metaclass_incompatibility for instance doesn't exist in CMOP, so in
a Moose - non-Moose - Moose inheritance setup, the non-Moose class needs
to get a Moose metaclass to run _fix_metaclass_incompatibility on to see
if it is going to need fixing (this isn't a big deal, since metaclass
compatibility means that it needs to have a Moose metaclass anyway, but
still something to watch out for).

So... any thoughts?

-doy