Returning self instead of void

John C. Randolph <jcr@nospam.idiom.com> wrote:
>
> ..also the same time that the 'in','out', and 'oneway' keywords were
> introduced, also to facilitate distributed objects.

Well, I'm not keeping track of the garbage that you are adding to the
Objective-C language, but I am sure that the "conversion script" that
is doing the conversion from Object to NSObject (where all the classes
that subclassed from Object were converted to subclass NSObject) was at
the same time doing the conversion from "return self" to (void).

Therefore, I think the "jihad" of Apple against "return self" must date
back to the time of the conversion script from Object to NSObject.

Glenn Andreas <gandreas@no.reply> wrote:
>
>> The reason is just that returning self makes life more difficult for people
>> who are calculating -retain/-release messages.
>
> Now _that's_ nonsense. Can you substantiate that claim in any way,
> shape, or form? I thought not...

After all, the silly rules are that depending on whether you get an object
as a "return value" or depending on whether you have created the object
yourself, you are supposed to autorelease,retain, release it whatever.

The bad design of autorelease pools is due to the imprecise definition of
"ownership" of objects.

The silly people at Apple apparently believed that if they removed the useful
feature of "return self" from the practice, they eliminated the "ownership"
problem of the "self" object, is it owned by the sender, or by the receiver,
or by the message that gets "self" back as return value ?

Michael Ash <mail@mikeash.com> wrote:
>
> The existance of any return value makes 'oneway' messages, where the
> sender doesn't wait for a response, impossible.

Yes, with Apple, sending a message is working like UDP.

It's unreliable due to the fact that the receiver has probably received
a segmentation fault due to an autorelease pool crash :-)

David Stes wrote:
>
> Glenn Andreas <gandreas@no.reply> wrote:
> >
> >> The reason is just that returning self makes life more difficult for people
> >> who are calculating -retain/-release messages.
> >
> > Now _that's_ nonsense. Can you substantiate that claim in any way,
> > shape, or form? I thought not...
>
> After all, the silly rules are that depending on whether you get an object
> as a "return value" or depending on whether you have created the object
> yourself, you are supposed to autorelease,retain, release it whatever.
>
> The bad design of autorelease pools is due to the imprecise definition of
> "ownership" of objects.
>
> The silly people at Apple apparently believed that if they removed the useful
> feature of "return self" from the practice, they eliminated the "ownership"
> problem of the "self" object, is it owned by the sender, or by the receiver,
> or by the message that gets "self" back as return value ?

Let the record show, that Stes failed to substantiate his claim.

-jcr

In article <gandreas-8E0039.12565827112003@news.mpls.visi.com>,
Glenn Andreas <gandreas@no.reply> wrote:

> > The reason is just that returning self makes life more difficult for people
> > who are calculating -retain/-release messages.
>
> Now _that's_ nonsense. Can you substantiate that claim in any way,
> shape, or form? I thought not...

Of course he can substatiate it. In nineteen-ninety-whatever, NeXT
completely revamped their ObjC system, as part of their personal
vendetta against David Stes. As part of this vendetta, they used mind
control rays against the aforementioned Mr. Stes to make him believe
that his old code would no longer work, thus forcing him to abandon the
platform. NeXT's takeover of Apple has not affected their prosecution of
this vendetta, and so it is clear to see that everything that came from
NeXT or comes from Apple is the pure distilled essence of Satanic Evil.

John C. Randolph <jcr@nospam.idiom.com> wrote:
>>
>> The bad design of autorelease pools is due to the imprecise definition of
>> "ownership" of objects.
>>
>> The silly people at Apple apparently believed that if they removed the useful
>> feature of "return self" from the practice, they eliminated the "ownership"
>> problem of the "self" object, is it owned by the sender, or by the receiver,
>> or by the message that gets "self" back as return value ?
>
> Let the record show, that Stes failed to substantiate his claim.

I'm just saying that the simple solution of Apple was: don't return self!

Well, that's all fine, but this unfortunately also makes the Objective-C
language less expressive, because it is very convenient to be able to
cascade (nest) messages, due to the "return self" practice.

In article <W0sxb.46762$xX1.1629315@phobos.telenet-ops.be>,
David Stes <stes@D5E02895.kabel.telenet.be> wrote:

> Michael Ash <mail@mikeash.com> wrote:
> >
> > The existance of any return value makes 'oneway' messages, where the
> > sender doesn't wait for a response, impossible.
>
> Yes, with Apple, sending a message is working like UDP.
>
> It's unreliable...[snip other nonsense]

Fascinating. Please point out where I specified that this process was
unreliable. It is, in fact, not unreliable. You can still find out if
the connection died; if it didn't die, you know that your message went
through.

Do you *really* want [object update] to wait for a response that just
returns object, when object is sitting on a machine at the end of a 2400
baud SLIP line in the middle of the Australian Outback? Not forcing
roundtrip latency on every message you send is a good thing.

Michael Ash <mail@mikeash.com> wrote:
>
> In nineteen-ninety-whatever, NeXT completely revamped their ObjC system

They used to use "return self" like anybody else.

Like POC, like Stepstone etc.

But at the time they converted their stuff from Object to NSObject, then
they made the change to (void) messages.

Michael Ash <mail@mikeash.com> writes:

> In article <gandreas-8E0039.12565827112003@news.mpls.visi.com>,
> Glenn Andreas <gandreas@no.reply> wrote:
>
> > > The reason is just that returning self makes life more difficult for people
> > > who are calculating -retain/-release messages.
> >
> > Now _that's_ nonsense. Can you substantiate that claim in any way,
> > shape, or form? I thought not...
>
> Of course he can substatiate it. In nineteen-ninety-whatever, NeXT
> completely revamped their ObjC system, as part of their personal
> vendetta against David Stes. As part of this vendetta, they used mind
> control rays against the aforementioned Mr. Stes to make him believe
> that his old code would no longer work, thus forcing him to abandon the
> platform. NeXT's takeover of Apple has not affected their prosecution of
> this vendetta, and so it is clear to see that everything that came from
> NeXT or comes from Apple is the pure distilled essence of Satanic Evil.

Can I put that in the C.L.Objective-C FAQ? >:-)

S.

David Stes wrote:
>
> John C. Randolph <jcr@nospam.idiom.com> wrote:
> >>
> >> The bad design of autorelease pools is due to the imprecise definition of
> >> "ownership" of objects.
> >>
> >> The silly people at Apple apparently believed that if they removed the useful
> >> feature of "return self" from the practice, they eliminated the "ownership"
> >> problem of the "self" object, is it owned by the sender, or by the receiver,
> >> or by the message that gets "self" back as return value ?
> >
> > Let the record show, that Stes failed to substantiate his claim.
>
> I'm just saying that the simple solution of Apple was: don't return self!

Do you have a better solution for limiting network traffic in a
distributed objects system? While you're at it, can you propose a
memory management scheme that deals with references that may be held by
another process on another host?

> Well, that's all fine, but this unfortunately also makes the Objective-C
> language less expressive, because it is very convenient to be able to
> cascade (nest) messages, due to the "return self" practice.

It may be convenient, but it was sloppy to simply depend on methods
returning self instead of checking their return values. Many methods
returned nil upon failure, for example.

-jcr