<div dir="ltr">Existing reference kinds, namly layout-before (until it's removed), layout-after and in-group, have clear semantics that is already implemented in the layout pass. For example, hen you create a reference from atom A to B with a layout-after reference, B will be always placed after A. Allowing users to redefine such basic relationship is more confusing than good. It's like redefining an operator, so caution needed.<div>


<br></div><div>Do you have any immediate need to subclass it? Because we have the entire codebase, we can add such abstraction when we need it, so doing it beforehand for future possible use tend to be overdesigning stuff.</div>


<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 27, 2014 at 8:57 AM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div text="#000000" bgcolor="#FFFFFF">
    Hi,<br>
    <br>
    I think it would be great if we could subclass the LayoutPass. <br>
    <br>
    All the generic functionality could be in the parent to run the
    layout-after/in-group/ and currently the layout-before passes(until
    it gets removed).<br>
    <br>
    Flavors can <b>choose to run the layout passes</b> that they use
    and determine the way things get ordered in the layout pass.<br>
    <br>
    The compare function in the LayoutPass would call  doLayoutAfter,
    doInGroup.<br>
    <br>
    Any concerns on sub-classing ?<br>
    <br>
    Thanks<span><font color="#888888"><br>
    <br>
    Shankar Easwaran<br>
    <pre cols="72">-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation</pre>
  </font></span></div>

</blockquote></div><br></div></div>