Re: BUILD and how to create a subclass object when creating a parent

Dear Marco,

Thanks for your reply. Discussion on what containers might be, is not 
what I'm looking for. The question is about Moose and how it could and 
could be used. Formulated less open than before: is there an option for 
an execution order that is the inverse of Method modifiers?

Your final advise might be sound though, if the answer is no.

Kind regards,
Arjan.

On 25/04/18 23:07, Marco Silva wrote:
> Excerpts from Arjan Widlak - United Knowledge's message of 2018-04-25 22:41:52 +0200:
>> Hi Karen,
>>
>> Thank you for your reply. Sorry if it's not clear, let me try again with
>> a more concrete example.
>>
>> I have a class called Asset, with subclasses like so:
>>
>> Asset
>> Asset::Container
>> Asset::Container::KDU
>>
>> Assets are objects to be displayed, Containers are Assets, but can
>> contain other Assets and Knowledge Delivery Units are a special kind of
>> containers.
>>
>> I have a similar group of classes with subclasses like so:
>>
>> Response
>> Response::Container
> Container idea is generally a list (a data structured to hold the type
> you are holding). Anything different than that is just simply confusing
> and should be avoided.
>
>> A Response is some response on an Asset by a user. The
>> Response::Container subclass sees if all Assets in a Container have
>> received a Response. It's like a summary of it's parent class.
>>
>> Now the problem. If I create a Response, I might like to create a
>> Response::Container instance as well. If the Response I am about to
> Why not simple add the Response to the container ?
> my $r = Response->new;
> $container->add($r);
>
>> create is the last Response needed for all Assets in the Container to
>> have received a Response, than I would like to create a
>> Response::Container subclass instance.
> Makes no sense.
>
>> So creation of an instance of a subclass - Response::Container - is only
>> dependent on the creation of the parent class - Response. Therefore it
>> seems like a good design choice to couple this to the create method of
>> Response. (Where the create method does new, update the database, and
>> new_by_id, to re-instantiate from the database.)
> Again, you don't create a new instance for container otherwise is not
> containing more then one item inside.
>
>> How does the Moose framework envision such a case? I expected BUILD to
>> be the answer. It causes a deep recursion, so it's definitely not, as is
>> well documented. Around also causes a deep recursion by default if one
>> does this, that can be avoided though by creating an empty subroutine in
>> the subclass. Quite error prone, so not the obvious choice.
>>
>> Since many of the ideas in Moose - Roles, Method modifiers, etc. - are
>> design ideas, I thought there is probably a view on cases like this.
>> However I cannot find the obvious way to to couple the creation of a
>> subclass to the creation of a parent class in Moose. How would one be
>> expected to do this in Moose?
>>
>> Kind regards,
>> Arjan.
> Probably you should try another design. A simple one
>

• BUILD and how to create a subclass object when creating a parent by Arjan Widlak - United Knowledge
• Re: BUILD and how to create a subclass object when creating a parent by Karen Etheridge
• Re: BUILD and how to create a subclass object when creating a parent by Arjan Widlak - United Knowledge
• Re: BUILD and how to create a subclass object when creating a parent by Arjan Widlak - United Knowledge
• Re: BUILD and how to create a subclass object when creating a parent by Marco Silva
• Re: BUILD and how to create a subclass object when creating a parent by Arjan Widlak - United Knowledge
• Re: BUILD and how to create a subclass object when creating a parent by Chris Prather
• Re: BUILD and how to create a subclass object when creating a parent by Thomas Klausner
• Re: BUILD and how to create a subclass object when creating a parent by Arjan Widlak - United Knowledge