Re: Create Phase

[Roger M. Burkhart]

> I don't understand the necessity to have an explicit
> part of initialisation for an object.
> 
> What is the difference between the implicit:
>  aThing = [Thing new: (int) aColor];
> 
> and the explicit:
>  aThing = [Thing createBegin: aZone];
>  [aThing setColor: (int)aColor];
>  aThing = [createEnd];
> 
> ------------------------------------------
> Bruno CUVELIER

Glen Ropella already answered with a web paper about some of the larger
motivations for a separate create phase.  For the specific case you raise,
it's admittedly not strictly necessary, but it becomes more and more
valuable the more there are different options that could appear between
the createBegin and createEnd.  If there's just one that you always use,
there's not as much gain.  Even then, however, note that your message:

  [Thing new: (int)aColor]

would also preclude the use of a message on some other, completely
unrelated class taking an "new" message argument of a different type, due
to declaration conflicts.  For example, the following messag declared on
another class could cause conflicts:

  [OtherThing new: (id)initArg]

Also, we do require an explicit zone argument whenever a new top-level object
is created.  That zone argument is missing in the new message, but we include
it on a create: or createBegin: message at a standard place.

If there's only one initialization argument that's often used, our plan is
to provide convenience messages that combine the create message and the
one initialization.  In such cases we'd use the following form of message:

  [Thing create: aZone setColor: (int)aColor]

This would be defined to be exactly equivalent to:

  aThing = [Thing createBegin: aZone];
  [aThing setColor: (int)aColor];
  aThing = [createEnd];

Not many of these convenience combinations have been created so far, but
our plan is to review all libraries for when they'd make sense and to
provide them as part of finalized interfaces for libraries.  But since
they don't provide any new function (by definition) this hasn't happened
much yet.  Meanwhile, we use the long, explicit form just because it
standardizes everything that's required, while leaving flexibility for
custom "set" messages (including argument types) on a per-object basis.

Roger Burkhart