Returning self instead of void - Programming Languages

This is a discussion on Returning self instead of void - Programming Languages ; Glenn Andreas wrote:[color=blue] > > In article <QtMzb.60631$vi7.2456687@phobos.telenet-ops.be>, > David Stes <stes@D5E02895.kabel.telenet.be> wrote: >[color=green] > > Stefan Arentz <stefan.arentz@soze.com> wrote:[color=darkred] > > >> > > >> So : in Objective-C, you can "return self" just fine. > > > > ...

+ Reply to Thread
Page 12 of 24 FirstFirst ... 2 10 11 12 13 14 22 ... LastLast
Results 111 to 120 of 232

Returning self instead of void

  1. Default Re: Returning self instead of void

    Glenn Andreas wrote:[color=blue]
    >
    > In article <QtMzb.60631$vi7.2456687@phobos.telenet-ops.be>,
    > David Stes <stes@D5E02895.kabel.telenet.be> wrote:
    >[color=green]
    > > Stefan Arentz <stefan.arentz@soze.com> wrote:[color=darkred]
    > > >>
    > > >> So : in Objective-C, you can "return self" just fine.
    > > >
    > > > Yes you can. But there is no rule that you should.[/color]
    > >
    > > No of course not. But it is convenient, that you can add multiple objects
    > > to a collection for example, like this:
    > >
    > > [[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]

    Exactly.

    In fact, I would argue that:

    [myCollection addbj1];
    [myCollection addbj2];
    ....
    [myCollection addbjn];

    is a win over

    [[[[[[[[myCollection
    addObjectbj1]
    addObjectbj2]
    ...
    addOjectbjn];

    because in the first case, I can add or remove one of the -add: messages
    without having to go back to the first line and balance the square brackets.

    -jcr

  2. Default Re: Returning self instead of void

    "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]



  3. Default Re: Returning self instead of void

    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.


  4. Default Re: Returning self instead of void

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


  5. Default Re: Returning self instead of void

    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.


  6. Default Re: Returning self instead of void

    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" ?


  7. Default Re: Returning self instead of void

    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.



  8. Default Re: Returning self instead of void

    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.


  9. Default Re: Returning self instead of void

    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.

  10. Default Re: Returning self instead of void

    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.


+ Reply to Thread
Page 12 of 24 FirstFirst ... 2 10 11 12 13 14 22 ... 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