Returning self instead of void - Programming Languages

Raffael Herzog wrote:[color=blue]
>
> John C. Randolph <jcr@nospam.idiom.com> wrote:
>[color=green]
> > There is a cost of waiting for that acknowledgement, which is
> > somewhat
> > less than waiting for the acknowledgement *and* marshalling a return
> > value.[/color]
>
> But the acknowledgement could simply state: "self has been returned" -
> no need to unmarshal anything anymore.[/color]

Not so, since ivars may have changed in the instance on the remote host.
DO treats all return values the same way, whether it's self, or some
other object that gets returned.

-jcr

In article <mail-11D5E7.11133429112003@localhost>,
Michael Ash <mail@mikeash.com> wrote:
[color=blue]
> In article <ESZxb.49718$Zt1.1608841@phobos.telenet-ops.be>,
> David Stes <stes@D5E02895.kabel.telenet.be> wrote:
>[color=green]
> > As long as you can't use "nested" message sends to remote objects, it seems
> > pretty restricted and a crippled unfinished immature implementation.[/color]
>
> I realize this may be difficult for you to grasp, but there is a simple
> algorithm for transforming nested sends to non-nested sends. For
> example, the sequence of:
>
> [[[obj foo] bar] baz]
>
> Becomes:
>
> [obj foo];
> [obj bar];
> [obj baz];
>
> There, that wasn't so hard, was it?[/color]

Also important is that this makes clear that 'obj' is the receiver of
all these messages, whereas you have to chase the message sends in the
first case to find this out.

Smalltalk has the ; to indicate multiple sends to the same receiver:

obj foo; bar; baz.

So the implicit 'self' return isn't used there.

Marcel

John C. Randolph <jcr@nospam.idiom.com> wrote:
[color=blue]
> Raffael Herzog wrote:[color=green]
>>
>> But the acknowledgement could simply state: "self has been
>> returned" -
>> no need to unmarshal anything anymore.[/color]
>
> Not so, since ivars may have changed in the instance on the remote
> host.
> DO treats all return values the same way, whether it's self, or
> some
> other object that gets returned.[/color]

Well, of course it depends on how DOs are implemented, maybe I'm just
too much into Java. But why should the whole object with all ivars be
(un)marshalled? A stub for the remote object is perfectly enough. If
self is returned, it's guaranteed that the client already has the
correct stub, so it (the stub) doesn't need to be serialized to the
client again, but setting a flag in the acknowledgement does the job
just fine.

Or am I on the completely wrong track?

cu,
Raffi (new to ObjC)

--
Neu im Usenet? Fragen? -> [url]http://www.use-net.ch/usenet_intro_de.html[/url]

Raffael Herzog - [email]herzog@raffael.ch[/email] - [url]www.raffael.ch[/url] - ICQ #67961355

Raffael Herzog <devnull@raffael.ch> wrote:[color=blue]
>
> maybe I'm just too much into Java.[/color]

No, you're not.
[color=blue]
> Or am I on the completely wrong track?
>
> cu,
> Raffi (new to ObjC)[/color]

You are on the right track.

In fact, this has nothing to do with ObjC versus JAVA.

Good programmers can implement things in both ObjC and Java, in a sensible
way. A certain "programming style" is what you get, regardless of the language.

Of course, the reverse is also true; "bad" programmers will produce bad
solutions, whether it is in Objective-C or Java.

The crippled distributed objects that is not even able to deal with cascaded
messages, is one such example.

In article <8R2yb.50674$wt1.1579120@phobos.telenet-ops.be>,
David Stes <stes@D5E02895.kabel.telenet.be> wrote:[color=blue]
> Good programmers can implement things in both ObjC and Java, in a sensible
> way. A certain "programming style" is what you get, regardless of the
> language.[/color]

You mean like exceptions?
[color=blue]
> Of course, the reverse is also true; "bad" programmers will produce bad
> solutions, whether it is in Objective-C or Java.[/color]

You mean like subclassing Color from String?

In article <8R2yb.50674$wt1.1579120@phobos.telenet-ops.be>,
David Stes <stes@D5E02895.kabel.telenet.be> wrote:
[color=blue]
> The crippled distributed objects that is not even able to deal with cascaded
> messages, is one such example.[/color]

So, uh, have you implemented a DO system? All I can find on your page is
this precompiler, and a bar chart generator.

David Stes <stes@D5E02895.kabel.telenet.be> wrote in message news:<nDqxb.46553$rt1.1574013@phobos.telenet-ops.be>...[color=blue]
> Normally, in Objective-C you also "return self".[/color]

As usual, this depends on the class library you're using. Cocoa, for
instance, does _not_ use the 'return self' convention.
[color=blue]
> This is very convenient as it allows you to "cascade" (nest) messages,[/color]

'cascading' and 'nesting' are actually different things. 'Nesting' is
the general ability to have one message-send expression inside
another, sich that the return value of the inner message-send can be
used by the outer message-send expression as the receiver or as one of
the actual arguments. For instance,

[[aCollection objectAtIndex:14] fooWithBar:[Bar bar]];

uses nested messages.

'Cascasing' is the specific concept of sending multiple messages to
the same object, without having to specify the object itself more than
once. In Smalltalk, there is a special syntax for this: What would be
expressed without cascading as

anObject foo.
anObject bar.
anObject fubar.

can be done using Smalltalk's cascading message-send syntax as

anObject foo; bar; fubar.

The semicolons (';') separate the different message-sends, but also
signify that the next message-send should go to the same receiver as
the previous one, _not_ to the object that was _returned_ from the
previous message.
[color=blue]
> as in :
>
> [[[myObject foo] bar] fubar];[/color]

Objective-C doesn't actually _have_ cascading messaging, so this is
how one might in Objective-C try to use nested message-sends to
emulate Smalltalk's cascading messages. This relies on each method
returning the original receiver of the message, essentially doing
'return self', which means that the return value from such a
message-send can be used as the receiver for another message-send,
which should result in that message being sent to the same object.

It may be 'convenient', but it actually somewhat dangerous. That
sequence of message-sends relies on every message returning 'self', in
order for those messages to all be sent to 'myObject'. Now consider
what happens if the 'bar' method gets changed slightly so that it
might return a different object - now it is that different object that
gets the 'fubar' message sent to it! Or consider what might happen in
the case of using a wrapper object, i.e., one that passes some of its
messages on to another object. Obviously, all the messages _should_ go
to the wrapper object - but of the wrapped object 'returns self', then
the wrapper object would have to inspect every value returned from its
wrapped object and replace any 'self' pointers, and all just to
support this 'convenience'.

In the absence of an explicit message cascading syntax, it's a lot
safer to send each message explicitly to the object you want to
receive the message:

[myObject foo];
[myObject bar];
[myObject fubar];

In this case, if the 'bar' method were to change which object it
returns, there will be no change in the behaviour of the program.
Likewise a 'wrapper' object doesn't need to worry about the wrapped
object returning self and thus 'breaking through the wrapper'.

Even better, if the original ber method were declared as -(void)bar;
then it would be immediately
obvious that the updated method -(id)bar; had different semantics,
which thus gives the entire system (developer, compiler, etc) an
immediate clue that something has changed.

I consider it to be simply good practice to use the most precisely
describing argument and return types that match what a function or
method is taking as arguments and returning. If a method doesn't
return a value of its own, to me that makes 'void' the most
appropriate return type for that method.

Returning 'self' from such methods instead of 'void' is one of those
things that may seem convenient at the time, but which in the long run
just turn out to add complications and have other repercussions that
weren't thought of. Such as the addition of unnecessary overhead in a
distributed-object environment - where suddenly, returning a reference
to an object is a significantly more costly operation than returning
nothing (whereas within the same machine, the performance difference
is negligible).

So on the one hand we have the 'convenience' of being able to cascade
messages to the same object, which can be done just as easily by just
writing each message send separately and spelling out the same object
explicitly; and on the other hand we have significant performance
implications.
[color=blue]
> At some point, Apple had the idea to change their classes to not return
> self, and they wrote a script to change all their "return self" statements
> and delete them, and slap a (void) in front of their method declarations.[/color]

Oh? Can you please identify this script and post a precise reference
to this script?

Of course he can't, because such a script is a figment of David Stes'
imagination. NeXT did write scripts to ease the transition of code
from using the NeXTStep classes to using the OpenStep ones, but the
NeXTStep classes themselves weren't changed - they were left as they
were, so that existing code would contunie to work unchanged. Instead,
OpenStep introduced a new, separate, parallel class hierarchy
precisely so that the two could be intermingled with impunity. So
while neXT did adopt a different convention in OpenStep than they had
used in NeXTStep, that's a far cry from what David Stes claims above.
[color=blue]
> I suspect they did this, because at the time they introduced their memory
> management (where the +new messages were replaced by their +alloc/autorelease
> stuff)[/color]

NeXT used +alloc/-init even before they introduced the OpenStep
classes; and +new is still available, as

+new { return [[self alloc] init]; }

which offers the same functionality, but is simply implemented on an
OO substrate rather than directly on a C-based one.
[color=blue]
> they wanted to simplify their "reference" count rules by having less
> objects (return values) exchanged between sender and receiver of messages.[/color]

The reference counting rules are not affected by whether a method
returns 'self' or not. If David Stes had actually understood Cocoa's
reference counting, he would know this - but either he _hasn't_
understood, or he is deliberately trying to spread FUD.

Best wishes

// Christian Brunschen

Christian Brunschen <cb@df.lth.se> wrote:[color=blue]
> David Stes <stes@D5E02895.kabel.telenet.be> wrote in message news:<nDqxb.46553$rt1.1574013@phobos.telenet-ops.be>...[color=green]
>> Normally, in Objective-C you also "return self".[/color]
>
> As usual, this depends on the class library you're using. Cocoa, for
> instance, does _not_ use the 'return self' convention.[/color]

The part that has problems with 'return self' is, according to J.Randolph
of Apple, their remote messaging.

For local messaging, it probably is still OK to use 'return self', although
that you have the problems of 'ownership' (with their release/retain stuff).

So assuming that in a future version of remote messaging, the current
limitation (it doesn't support 'return self' yet) is lifted, 'return self'
will work again in the future.

In article <R1pyb.52993$DJ2.1693825@phobos.telenet-ops.be>,
David Stes <stes@D5E02895.kabel.telenet.be> wrote:
[color=blue]
> For local messaging, it probably is still OK to use 'return self', although
> that you have the problems of 'ownership' (with their release/retain stuff).[/color]

No you don't. You've been told this repeated. It has been explained
ad-naseum. Yet you continue to spout these falsehoods. Why?