<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 3, 2013 at 4:36 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br>
<div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<span class="" style="color:rgb(34,34,34)">So for me it is important that a class can belong to more than one package.</span><br></div>
</blockquote></div><br></div><div class="gmail_extra">Me too. I've used this feature while splitting monolithic packages into multiple packages that can be loaded independently, not to manage a mistake, but to make the process easier as I went.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I've also used it when developing tools like Monticello and OmniBrowser. The tests inevitably involve making code changes, and I've found it handy to have a sub-package containing only those bogus classes that get changed by the tests. When things don't get cleaned up properly because of broken tests or tools, I can fix things by just loading the sub-package to revert all changes.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Colin</div></div>