Re: Question about createEnd.

[Ken Cline]

"Paul E. Johnson" wrote:
> 
> > ----------
> > From:         Paul E. Johnson[SMTP:address@hidden
> > Sent:         Tuesday, January 05, 1999 4:13:26 PM
> > To:   swarm
> > Subject:      Question about createEnd.
> > Auto forwarded by a Rule
> >
> I have been puzzling over a matter of style in the swarm tutorial and
> wonder what y'all think.
> 
> The question is this.  In createEnd methods, when there is nothing in
> particular to do, one finds this:
> 
>  return [super createEnd];
> 
> along with a comment that this is included to show the user that
> createEnd statements can be customized.
> 
> If I were writing the tutorial, I would do this instead, because it
> seems more
> clear:
> 
>   [super createEnd];
>   [return self];
> 
> Does this have the same effect? I think yes. ...

The two code fragments are not exactly the same...
    return [super createEnd]
passes back a pointer to whatever the superclass's createEnd
method returns.

Where as
   [super createEnd];
   return self;
always passes back the handle to the current object.

The two would be the same only if the implementation of the
superclass's createEnd method was:
   -createEnd {
       ...
       return self;
   }

> ... The other way is difficult for me to get my mind around. The
> return from [super createEnd] is the self of the superclass, and
> this returns that. What does that mean?

The "self of the superclass" is the same object handle/pointer as
the "self of the subclass".  You might think of "self" as just a 
special *instance* variable which all objects have.  I believe its
even possible for a superclass to anticipate subclass extensions,
for example the *superclass* could contain a method like:

    - (char *) whoami {
        if ( [ self isKindOf: subclassA ] )
           return "A";
        if ( [ self isKindOf: subclassB ] )
           return "B";
        return "?"
    }
(Please forgive syntax mistakes, I haven't written any C or ObjC for 6+
monthes and I don't have a reference manual with me.)  However,
I would consider the implementation above "bad style" and I'm not
sure the compiler would approve either.  I was just trying to illustrate
that there is only one "self" for each instance.

It is my understanding that the reason the Swarm-style suggests
     return [super createEnd];
is because this allows a superclass's createEnd the flexibility
to passback whatever it has determined would be the most suitable
object based on "create-time messages" it has been sent since
createBegin was initially called.  For example, if a client object
wants some type of collection and at "create-time" specifies that
the collection will have a fixed length, n, then maybe the createEnd
method returns an instance of an Array.  Otherwise the createEnd
method might just return an instance of a List.  I'm not sure,
however, if any Swarm objects actually use this capability.

> Furthermore, if there were some customization in the user's createEnd
> command, then it could be put in here:
> 
>   [super createEnd];
>     {customized createEnd statements}
>   [return self];
> 
> If the [super createEnd] causes the superclass to initialize a variable
> that is then called in
> the customized statements in the subclass, I don't see any other way to
> do it.

You raise a good point that sometimes it is preferable (even required)
to do subclass "customization" after the superclass's createEnd method
has been executed.  In this case, you might implement the subclass's
createEnd like:

   -createEnd {
       id obj = [ super createEnd ];
          ...
       {customized createEnd statements of the form: '[ obj foo: arg ]'
}
          ...
       return obj;
   }

This should be correct no matter what the superclass's createEnd method
returns.

I hope that helps...

Ken.

PS: Happy New Year!

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.