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

[email protected] (Arjan Widlak - United Knowledge) Thu, 26 Apr 2018 17:21:35 +0200
Newsgroups	perl.moose
Message-ID	<[email protected]>
--------------BD2C54590E41F97B7FE12B32
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Thanks all. I got it to work, but yes, I'm going to rethink the design 
anyway.

For those who are interested in how it can be done:

Asset::Container::KDU1        Response1 Response::Summary1
Del-> Asset::Container::KDU2 (6)    Response2 (5) Response::Summary2 (4)
Asset::Container::KDU3 (3)    Response3 (2) Response::Summary3 (1)

Cascading a delete from (1) to (6) with a delete method on (6) works with:
- A 'before delete' in Asset::Container, that iterates through it's 
direct children in the lineage.
- A 'before delete' in Asset, that iterates through it's own Responses.
- And finally a 'before delete' in Response that iterates through the 
Summaries.

But true, this is too complex. And so would Inner and Augment be. Not 
transparent enough.

Thanks for the feedback!

Kind regards,
Arjan.


On 26/04/18 13:52, Thomas Klausner wrote:
> Hi!
>
> On Thu, Apr 26, 2018 at 07:45:58AM -0400, Chris Prather wrote:
>
>>> 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.
>>>
>> Look at augment/inner but experience says that if you’re reaching for this you need to rethink your design because you’re over coupling something somewhere.
> And while it might be possible to coerce Moose to do what you want
> automagically, I think it makes for much better / easier to
> understand code if you "just" create some methods that explictly do what
> you need. That way your future self can just read what's happening
> without having to hunt through several layers of Moose magic...
>
> Greetings,
> domm
>


--------------BD2C54590E41F97B7FE12B32
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Thanks all. I got it to work, but yes,
      I'm going to rethink the design anyway. <br>
      <br>
      For those who are interested in how it can be done:<br>
      <br>
      <font face="Courier New, Courier, monospace">     
        Asset::Container::KDU1        Response1       
        Response::Summary1<br>
        Del-&gt;  </font><font face="Courier New, Courier, monospace"><font
          face="Courier New, Courier, monospace">Asset::Container::</font>KDU2
        (6)    Response2 (5)    </font><font face="Courier New,
        Courier, monospace"><font face="Courier New, Courier, monospace">Response::</font>Summary2
        (4)<br>
                </font><font face="Courier New, Courier, monospace"><font
          face="Courier New, Courier, monospace">Asset::Container::</font>KDU3
        (3)    Response3 (2)    </font><font face="Courier New,
        Courier, monospace"><font face="Courier New, Courier, monospace">Response::</font>Summary3
        (1)</font><br>
      <br>
      Cascading a delete from (1) to (6) with a delete method on (6)
      works with:<br>
      - A 'before delete' in Asset::Container, that iterates through
      it's direct children in the lineage. <br>
      - A 'before delete' in Asset, that iterates through it's own
      Responses. <br>
      - And finally a 'before delete' in Response that iterates through
      the Summaries. <br>
      <br>
      But true, this is too complex. And so would Inner and Augment be.
      Not transparent enough. <br>
      <br>
      Thanks for the feedback!<br>
      <br>
      Kind regards,<br>
      Arjan.<br>
      <br>
      <br>
      On 26/04/18 13:52, Thomas Klausner wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:[email protected]">
      <pre wrap="">Hi!

On Thu, Apr 26, 2018 at 07:45:58AM -0400, Chris Prather wrote:

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">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.

</pre>
        </blockquote>
        <pre wrap="">
Look at augment/inner but experience says that if you’re reaching for this you need to rethink your design because you’re over coupling something somewhere.
</pre>
      </blockquote>
      <pre wrap="">
And while it might be possible to coerce Moose to do what you want 
automagically, I think it makes for much better / easier to 
understand code if you "just" create some methods that explictly do what 
you need. That way your future self can just read what's happening 
without having to hunt through several layers of Moose magic...

Greetings,
domm

</pre>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>

--------------BD2C54590E41F97B7FE12B32--