Returning self instead of void - Programming Languages

"David Stes" <stes@D5E02895.kabel.telenet.be> wrote in message
news:%hBzb.59401$kC6.2064502@phobos.telenet-ops.be...[color=blue]
> John C. Randolph <jcr@nospam.idiom.com> wrote:[color=green][color=darkred]
> >>[/color][/color][/color]
[snip][color=blue]
> The question was : is it good practice to "return self".
>
> The answer is: YES.[/color]

Wrong. The answer is NO. You are posing a *general* *unqualified*
question. By phrasing the question in the way you have done you are asking
"is it good practice to 'return self' in all implementations of
objective-c?".

Again and again you fail to understand that, in the absence of a standard,
there is not *one* objective-C. That means that there is not one language,
or one runtime, or one class library. You control a particular
implementation of objective-C in the form of POC. You make design choices
like returning self, feel free to tell us why you use them, but if you have
any kind of intelligence then respect the choices made by others. What
Apple chooses to do does not impact what you choose to do with POC in any
way. Your implementation is as valid as theirs and vice-versa. So keep
quiet and stop moaning.

You also fail to understand that, in the absence of a standard, the argument
"because it has always been that way" is also complete rubbish. Languages
evolve, they change. If someone spots part of a class library that is not
always safe, for example, say, like returning self, then they can bin it in
their own implementation. Especially if that "feature" results in crappy
syntax, and poor use of the language. Stuff precedent. If something is
daft then roll on change. Everyone has a right to their own decisions and
their own implementation. I dread to think what your politics are like, you
must be one scary person.

Please learn to control your language. Maybe english isn't your first
language? Do you know how to write it? Hint - unqualified statments are
assumed to mean in the general case, which usually encompasses everything.
Perhaps you need to be introduced to the concept of subjectivity, both in
language and reasoning.

Peter
[color=blue]
> [lots of misinformed trash about retain/release snipped][/color]

jordan muscott <spamdard_in@yahoo.co.uk> wrote:[color=blue]
>
> the question was, why have we abandoned returning self?[/color]

We haven't abandonded "return self", it is just that Apple puts a lot
of emphasis on not using "return self".

Assuming that "someCollection", "myObject" and "otherObject" are proxies
at the client-side for objects on the server-side, then:

[[someCollection add:myObject] addtherObject];

can be assumed to add exactly (at the server side) the two arguments to
the collection. The question is whether D.O. is capable of dealing with
"return self", and a second question is, if it is not capable of dealing
with it, whether that warrants changing "return self" for local messaging,
because obviously for a few exceptions, one cannot change the rule.

Peter Mendham <pdm104@york.ac.uk> wrote:[color=blue]
>
> Again and again you fail to understand that, in the absence of a standard,
> there is not *one* objective-C.[/color]

In any case, there is no need to make the variants more differing than they
are.

This is why I doubt it is a good idea to take a system of a lot of Obj-C
code, and then start to remove the "return self" statement everywhere, merely
for performance reasons.

I seriously question whether a 500,000 lines of code without "return self"
performs any better than the same pile of code with "return self". After all,
"return self" is an extremely "inexpensive" operation (in terms of performance).

John C. Randolph <jcr@nospam.idiom.com> wrote:[color=blue]
>
> DO works just fine when returning any object or set thereof.[/color]

Suppose you have proxies at the client : myCollection, myObject, otherObject.

Suppose you do :

[[myCollection add:myObject] addtherObject];

is your DO capable of dealing with the "return self" and adding the objects
at the server side for which you have proxies at the client-side.

Obviously the server has to "acknowledge" that it has completed the first
"add:" operation. At that point, on the client side, the "return self"
(to return the proxy myCollection) is extremely inexpensive.

In fact, the overhead of returning - at the client-side - the 'myCollection'
object must be truly very few instructions, compared to the acknowledgement
for the completion of the -add: messages, whether they return "void" or not.

Michael Ash <mail@mikeash.com> wrote:[color=blue]
>
> you can return self. It may be slightly slower if you do so.[/color]

Ok, so if you really find out for a specific message that there is
intolerable overhead for returning self (which I doubt by itself, since
sending the acknowledgment that a message completed, is just as much work
as sending back the acknowledgement to return the receiver), but suppose
it is "too slow", then you can fix that for that particular message.

Why then change all messages to not "return self" ?

John C. Randolph <jcr@nospam.idiom.com> wrote:[color=blue]
>
> Stes is insisting that we stick to a
> convention that just doesn't make sense in the context of DO.[/color]

You just limit functionality.

If "someCollection" is a proxy for a remote object, if "myObject" is
a proxy, if "otherObject" is a proxy for a remote object, and if you instruct
a server to add myObject and otherObject to someCollection, then the
convention to "return the receiver" makes *PERFECT* sense:

[[someCollection add:myObject] addtherObject];

Why would this be less convenient for remote messaging than for local
messaging ?

In fact, I think it is really very bad, if the remote versus local choice,
would NOT be transparent.

If you have to think : oh, with remote messaging I can't "return self",
and with local messaging, you can, then the difference between remote and
local has not been solved in a *transparent* way.

Glenn Andreas <gandreas@no.reply> wrote:[color=blue][color=green]
>>
>> [[myCollection add:myObject] addtherObject];
>>
>> So there is no reason to remove this kind of functionality, not even if
>> "myCollection" is remote.[/color]
>
> And
> [myCollection add: myObject];
> [myCollection add: otherObject];
>
> is so hideous?[/color]

The point is not whether it is hideous, the point is whether the
convenience of the first snippet of code, is not exactly the same in the
local as in the remote case.

Obviously if you have local objects, you can do:

[[myCollection add:myObject] addtherObject];

I don't see why one would not do an effort to make this work in the remote
case.

Unless Apple doesn't have the resources to do this, to do the work on it,
and therefore chooses the "easy" route of simply saying programmers that they
shouldn't do it.

But that's the "lazy" approach, where you just limit functionality, merely
to make life easier for the developers at Apple. They have to work less, and
they simply make a rule "do not return self" in order to solve a particular
problem for them.

And I'm sure that "return self" is only the most obvious limitation of their
product; if something simple like that doesn't work, the product probably has
tons of other limitations.

In article <n%3Ab.62226$jo7.2531374@phobos.telenet-ops.be>,
David Stes <stes@D5E02895.kabel.telenet.be> wrote:
[color=blue]
> Why then change all messages to not "return self" ?[/color]

Because it's bad practice to write code that will break if somebody
later decides that a method should return something useful.

Michael Ash <mail@mikeash.com> wrote:[color=blue]
>[color=green]
>> Why then change all messages to not "return self" ?[/color]
>
> Because it's bad practice to write code that will break if somebody
> later decides that a method should return something useful.[/color]

It is exactly the other way around : I'd rather "return self" for in case
it turns out to be useful under some circumstances, later on, that are not
foreseen immediately.

For example, with remote messaging, it is definitely useful to be able to
do:

[[remoteCollection add:remoteObject] addtherRemoteObject];

This "expression" is useful, just as it is useful in the local case.