<div class="gmail_quote">On Wed, Feb 4, 2009 at 7:17 AM, Philippe Marschall <span dir="ltr"><<a href="mailto:philippe.marschall@gmail.com">philippe.marschall@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/2/4 Julian Fitzell <<a href="mailto:jfitzell@gmail.com">jfitzell@gmail.com</a>>:<br>
<div class="Ih2E3d">
> Shall we merge them or not?<br>
<br>
</div>Pier and Magritte would be good reason not to do it. And honestly if I<br>
have to write protable code I use WAPlatform ;-)<br>
</blockquote></div><br>Ok, so then we need to define what should actually be in that Package. So far we've just been putting stuff in there as it gets pulled in by load-order dependencies. Does WACodec belong in there? What about WADelayedSend? WAPrinter? All of these things are useful utilities that could *possibly* be useful to some other package but they're not really part of a basic compaibility platform.<br>
<br>WAError and WAObject could be useful I suppose but one of the things we wanted with WAObject was to be able to add methods to it for all Seaside objects and without worrying about name conflicts. If Pier and Magritte and everything are going to subclass WAObject too, then that is no longer an appropriate place to do that. We could perhaps have WAPlatformObject in Seaside-Platform that ensure consistent initialization and then a WAObject subclass in Seaside-Core that the rest of our objects subclass...<br>
<br>The contents of Seaside-Platform feel a bit random at the moment.<br><br>Julian<br>