in reply to Re^2: Problem generating builder functions with Moose for inherited objects
in thread Problem generating builder functions with Moose for inherited objects

Honestly, please feel free to tell me off for using SmartAss mode but I can't resist to make two comments :->

  1. Using Moose for a class that has attribute's you can't declare the Moose way sort of defeats the purpose of using Moose in the first place, doesn't it? Maybe you are better off doing this the "classical" way.
  2. Is it possible that these classes need to be re-designed? If you have more atributes than you can manage/declare then there might be something wrong with it. I don't claim to be a master OO designer at all but others here certainly are and it might be worth posting your design here to get some advice from other monks.
    My question would be, if this class has hundreds of attributes (or more?) then what does the API look like? How would you document it?

As for the attribute list: I think the behaviour that you are seeing makes sense. Yes, the parent's BUILD method is called but $self isa "Child", so $self->meta->get_attribute_list should return the Child classes attribute list as far as I can see.

  • Comment on Re^3: Problem generating builder functions with Moose for inherited objects

Replies are listed 'Best First'.
Re^4: Problem generating builder functions with Moose for inherited objects
by Neighbour (Friar) on Sep 02, 2010 at 10:33 UTC
    And right back at ya :)
    • This problem came into existence while converting classical OO to Moose. The old code used dynamic multiple inheritance to try (but not succeed completely) to implement, what was later explained to me, the functionality of roles. Unfortunately, the way it was implemented meant that once features were added to an instance using multiple inheritance, all instances of that class got those features (instead of just the single instance).
    • There are currently about 9 attributes in the Parent class, and an unspecified number in various child-classes. The fact that new child-classes (offering new roles) can be added with an arbitrary amount of (new) attributes (plus the fact that I can't be arsed to write 9 builder functions that return empty data :)) calls for the dynamic creation of builder functions (imho :P).

    From the Moose's mouth: http://search.cpan.org/~drolsky/Moose/lib/Moose/Manual/Construction.pod

    The BUILD method is called after an object is created.
    ...
    The interaction between multiple BUILD methods in an inheritance hierarchy is different from normal Perl methods. You should never call $self->SUPER::BUILD.
    Moose arranges to have all of the BUILD methods in a hierarchy called when an object is constructed, from parents to children.

    From which I concluded that first a parent object would be created and BUILD called, then the inheritance would kick in and the child's BUILD would be called.
    Anyway, given the current situation, I'd need to dynamically figure out how $self relates to __PACKAGE__ and create the appropriate builder functions (if they don't exist already). Or something completely different.

      Would it not be better to use proper Moose roles now that you are converting this to Moose? Otherwise I would really be wondering what you gain from the conversion? Sorry, I know you probably thought about all of this and I know it's a bit annoying when you ask a question and people start preaching "the one true path" at you but sometimes it may also helpful to run your reasoning past another person to arrive at new solutions...

      Anyway, I think the Moose documentation is not contradicting the observed (and probably expected) behaviour. Yes, the parent's BUILD method is called but the object is still of class "Child", not "Parent". It's like calling $self->SUPER::BUILD (which you shouldn't) - you call an inherited METHOD but the object you call it on doesn't change class, if that makes any sense?
      The fact that you get "Parent" from __PACKAGE__ doesn't mean that the object is of that class - it just means that this method is defined in the file that defines package "Parent".

        The idea was to use proper Moose roles, but I got sidetracked at the point where I used lazy_build=>1 and still had to generate builder-functions.

        I could fill you in on the details of the getup, but it would be inappropriate to do so in this thread.

        Besides that, your reasoning on $self rings true :)