Re: Create phase protocol...

[glen e. p. ropella]

> -createEnd {
>   id finalSelf;
> 
>   // Object initialisation prior to createEnd could be done
>   // here, *or* in an overridded createBegin...
> 
>   someInstanceVariable = someValue;
>   // We can still refer directly to instance variables here,
>   // because the self pointer is still valid...
> 
>   finalSelf = [super createEnd];
> 
>   // Object initialisation for after creatEnd should happen
>   // here...
> 
>   [finalSelf setSomeOtherInstanceVariableTo: someOtherValue];
>   // We *must* use messages here rather than direct refs to
>   // instance vars, because the self pointer is no longer
>   // valid?
> 
>   return finalSelf;
>   // MUST return finalSelf rather than (invalid) self....
> }

I'm not sure what "legitimately" means, here. :-) But, I think the
only thing you're missing when you don't call the super's createEnd is
the phase change from creating to using (if the super's createEnd
calls setNextPhase()), assuming you want your created structure to be
the exact same as the structure you're building during the create.

If I understand correctly, the create phase functionality was
only added to allow these two situations (different methods during
different phases and different "shape" during different phases).

Hence, if your agent is going to look and act the same despite
it's "phase," then there's really no reason to perform the ol'
Switcheroo.

To quote from Objective-C Swarm-Style:
--------------------------------------------------------------------
Since this form of object creation is still quite rare in the object
oriented community, we do not expect the users to write code which
actually implements this sort of technique. However, we do advise the
users to try and split those messages which are supposed to be sent
only once in the lifetime of an object (just after the object is
created) from the ones that are sent multiple times.
------------------------------------------------------------------

And, I think you can still return self at the end regardless of 
whether you call [super createEnd] or not.  (i.e. I don't
think the super's createEnd will destroy the self.)

For instance, in Schedule.m, we have

- createEnd
{
  if ( repeatInterval ) {
    if ( ( bits & Bit_RelTimeSet ) && ! ( bits & Bit_RelativeTime ) )
      raiseEvent( InvalidCombination,
        "cannot specify both a repeat interval and absolute time\n" );

    setBit( bits, Bit_RelativeTime, 1 );  // force relative time for repeat
  }
  [(id)self setCompareFunction: _activity_compareIDs];

  if ( createByMessageToCopy( self, createEnd ) ) return self;

  if ( ! concurrentGroupType ) concurrentGroupType = ActionGroup;
  if ( variableDefs ) [self _createVarDefsArray_];
  [super createEnd];
  return self;
}

and in the super (OrderedSet.m)

- createEnd
{
  createByCopy( );
  setNextPhase( self );
  return self;
}


which, I believe reassigns "self" to the copied object, increments
the phase, and returns the new self.

The end result being that if you don't call [super createEnd],
you're pointer never changes.  But, who cares if your object is 
expected to behave the same in each phase?

glen