[Seaside-dev] basicNew

[Julian Fitzell]

On Wed, Jan 7, 2009 at 12:40 AM, Keith Hodges <keith_hodges at yahoo.co.uk> wrote:
> SomeClass-i-#initializeWithWidth: wInteger height: hInteger depth:
>
> My thoughts are that this construct is redundant, and only serves to
> clutter up the instance side of the class. The user instanciating looks
> to the class side and finds an initializer whose role is to supply a
> "fully working instance", which it can supply.
>
> so...
>
> SomeClass-c-width: w height: h depth: d
>
> self basicNew
>    width: w;
>    height: h;
>    depth: d;
>    initialize
>    yourself
>
> These specialised initialize methods are only necessary if it has been
> decided that the instance variables are to have no setters.

Hi Keith,

Strictly speaking, of course, you're right in some cases (certainly
those where the initializer is doing nothing but setting instance
variables) but I don't think that works for all. For example:
 * There may be cases where other variables need to be initialized
based on the values of some of the initialization parameters (and
these may not necessarily want to be updated when using the setters
later). The action you take with the initial value may also depend on
how your superclass initializes itself.
 * A future subclass may want to do something with the initial values
of some of these parameters.
 * Your accessors may not work yet before the object has been initialized!

The pattern you suggest above also, I think, makes it less clear which
parameters are required for initialization. Each class has only one
initialization method (always prefixed with #initialize) but it may
have many instance creation methods on the class side, all of which
would need to be read through to figure out what is required for
initialization. Note that we are only talking about *required*
initialization values here; additional configuration can be done by
instance creation methods using any other instance methods, including
setters.

I think the conventions we agreed on have the advantages that they:
  (a) can be applied consistently in ALL cases,
  (b) are VERY clear about what is required for initialization, and
  (c) are unambiguous.

These may not be big advantages for all application code one writes,
but for a framework that others are extending I think they are
significant.

Julian