Returning self instead of void - Programming Languages

This is a discussion on Returning self instead of void - Programming Languages ; John C. Randolph <jcr@nospam.idiom.com> wrote:[color=blue] > > ..also the same time that the 'in','out', and 'oneway' keywords were > introduced, also to facilitate distributed objects.[/color] Well, I'm not keeping track of the garbage that you are adding to the Objective-C ...

+ Reply to Thread
Page 2 of 24 FirstFirst 1 2 3 4 12 ... LastLast
Results 11 to 20 of 232

Returning self instead of void

  1. Default Re: Returning self instead of void

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

    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.



  2. Default Re: Returning self instead of void

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

    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 ?


  3. Default Re: Returning self instead of void

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

    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 :-)



  4. Default Re: Returning self instead of void

    David Stes wrote:[color=blue]
    >
    > Glenn Andreas <gandreas@no.reply> wrote:[color=green]
    > >[color=darkred]
    > >> The reason is just that returning self makes life more difficult for people
    > >> who are calculating -retain/-release messages.[/color]
    > >
    > > Now _that's_ nonsense. Can you substantiate that claim in any way,
    > > shape, or form? I thought not...[/color]
    >
    > 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 ?[/color]

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

    -jcr

  5. Default Re: Returning self instead of void

    In article <gandreas-8E0039.12565827112003@news.mpls.visi.com>,
    Glenn Andreas <gandreas@no.reply> wrote:
    [color=blue][color=green]
    > > The reason is just that returning self makes life more difficult for people
    > > who are calculating -retain/-release messages.[/color]
    >
    > Now _that's_ nonsense. Can you substantiate that claim in any way,
    > shape, or form? I thought not...[/color]

    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.

  6. Default Re: Returning self instead of void

    John C. Randolph <jcr@nospam.idiom.com> wrote:[color=blue][color=green]
    >>
    >> 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 ?[/color]
    >
    > Let the record show, that Stes failed to substantiate his claim.[/color]

    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.


  7. Default Re: Returning self instead of void

    In article <W0sxb.46762$xX1.1629315@phobos.telenet-ops.be>,
    David Stes <stes@D5E02895.kabel.telenet.be> wrote:
    [color=blue]
    > Michael Ash <mail@mikeash.com> wrote:[color=green]
    > >
    > > The existance of any return value makes 'oneway' messages, where the
    > > sender doesn't wait for a response, impossible.[/color]
    >
    > Yes, with Apple, sending a message is working like UDP.
    >
    > It's unreliable...[snip other nonsense][/color]

    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.

  8. Default Re: Returning self instead of void

    Michael Ash <mail@mikeash.com> wrote:[color=blue]
    >
    > In nineteen-ninety-whatever, NeXT completely revamped their ObjC system[/color]

    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.


  9. Default Re: Returning self instead of void

    Michael Ash <mail@mikeash.com> writes:
    [color=blue]
    > In article <gandreas-8E0039.12565827112003@news.mpls.visi.com>,
    > Glenn Andreas <gandreas@no.reply> wrote:
    >[color=green][color=darkred]
    > > > The reason is just that returning self makes life more difficult for people
    > > > who are calculating -retain/-release messages.[/color]
    > >
    > > Now _that's_ nonsense. Can you substantiate that claim in any way,
    > > shape, or form? I thought not...[/color]
    >
    > 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.[/color]

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

    S.

  10. Default Re: Returning self instead of void

    David Stes wrote:[color=blue]
    >
    > John C. Randolph <jcr@nospam.idiom.com> wrote:[color=green][color=darkred]
    > >>
    > >> 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 ?[/color]
    > >
    > > Let the record show, that Stes failed to substantiate his claim.[/color]
    >
    > I'm just saying that the simple solution of Apple was: don't return self![/color]

    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?
    [color=blue]
    > 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.[/color]

    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

+ Reply to Thread
Page 2 of 24 FirstFirst 1 2 3 4 12 ... LastLast

Similar Threads

  1. g++ does not complain when not returning form non-void
    By Application Development in forum c++
    Replies: 2
    Last Post: 10-23-2007, 02:54 PM
  2. void *
    By Application Development in forum C
    Replies: 36
    Last Post: 07-04-2007, 07:10 AM
  3. void Foo (void** p) to VB URGENT!!
    By Application Development in forum basic.visual
    Replies: 1
    Last Post: 11-02-2006, 01:39 PM
  4. Why do we have void*?
    By Application Development in forum c++
    Replies: 11
    Last Post: 05-18-2006, 07:42 PM
  5. (void *)
    By Application Development in forum C
    Replies: 7
    Last Post: 01-22-2006, 06:27 PM