[Seaside-dev] merging Platform and Core

[Philippe Marschall]

2009/2/5 Julian Fitzell <jfitzell at gmail.com>:
> On Thu, Feb 5, 2009 at 7:42 AM, Philippe Marschall
> <philippe.marschall at gmail.com> wrote:
>>
>> 2009/2/4 Julian Fitzell <jfitzell at gmail.com>:
>> > 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.
>>
>> The problem is even worse becuase Magritte (I think) and Pier also add
>> root component classes that add methods. We also must not get a
>> conflict on them. So I think it's ok to say that if you use WAObject
>> then you have to make sure you get no conflicts because that is also
>> true for WAComponent.
>
> Hm... I don't seem to have written this but my point was only half about
> conflicts. The other point is about method visibility and error grouping.
>
> For errors, if you want to be able to catch all Seaside errors but not
> filesystem errors (for example), you'd want to be able to catch WAError but
> that doesn't work if Pier also subclasses WAError.
>
> For WAObject, do we want every object in Seaside to respond to
> #acceptMagritte: for example? Every object in Magritte to respond to
> #requestContext? I say definitely not.
>
> If we're going to set up this platform for use by other projects, I think we
> need to be careful to separate compatibility from convenience.
> WAObject>>initialize is compatibility; WAObject>>requestContext is
> convenience. Having an Error subclass that you know implents #signal: is
> compatibility; having an Error subclass that all of a project's errors
> subclass is convenience.

You're right. Righ now WA means Seaside. If we wanted to do this
change WA would have to be reduced to only mean portable.

Cheers
Philippe