[Seaside-dev] merging Platform and Core

[Julian Fitzell]

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.

Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20090205/e60c2669/attachment.htm