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
