Returning self instead of void - Programming Languages

This is a discussion on Returning self instead of void - Programming Languages ; Glenn Andreas <gandreas@no.reply> wrote:[color=blue] > > Of course, if one uses a message to add multiple objects, it renders > moot the issue of returning self from the "add single object" message > which is nested to add multiple objects.[/color] ...

+ Reply to Thread
Page 14 of 24 FirstFirst ... 4 12 13 14 15 16 ... LastLast
Results 131 to 140 of 232

Returning self instead of void

  1. Default Re: Returning self instead of void

    Glenn Andreas <gandreas@no.reply> wrote:[color=blue]
    >
    > Of course, if one uses a message to add multiple objects, it renders
    > moot the issue of returning self from the "add single object" message
    > which is nested to add multiple objects.[/color]

    I agree. If, for instance, for distributed objects, you write a message:

    - (void) mydistributemessage:a:b { [[self add:a] add:b]; }

    Then you hopefully agree that there is NO overhead at all associated to
    the "return self".

    This is what I've been telling for a while, namely that there is no need
    to change local messaging (return self) for the sake of remote messaging.

    Finally, it is also the case that to me, the *RELATIVE* overhead of
    return self, in the remote case, doesn't seem big.

    If it takes a few tens of thousands of instructions to encode a selector,
    to send it over the network, to dispatch it on the server, to acknowledge
    it has sent (and to signal that the receiver should be returned), then it
    is very inexpensive to actually return the receiver.

    The question remains of course : what is the "receiver" : it is the proxy
    for the remote object.


  2. Default Re: Returning self instead of void

    In article <fHqAb.63924$9q7.2554932@phobos.telenet-ops.be>,
    David Stes <stes@D5E02895.kabel.telenet.be> wrote:
    [color=blue]
    > Glenn Andreas <gandreas@no.reply> wrote:[color=green]
    > >
    > > Of course, if one uses a message to add multiple objects, it renders
    > > moot the issue of returning self from the "add single object" message
    > > which is nested to add multiple objects.[/color]
    >
    > I agree. If, for instance, for distributed objects, you write a message:
    >
    > - (void) mydistributemessage:a:b { [[self add:a] add:b]; }[/color]

    How do you transport a block across address spaces, or machines?

    Marcel

  3. Default Re: Returning self instead of void

    In article <fHqAb.63924$9q7.2554932@phobos.telenet-ops.be>,
    David Stes <stes@D5E02895.kabel.telenet.be> wrote:
    [color=blue]
    > Glenn Andreas <gandreas@no.reply> wrote:[color=green]
    > >
    > > Of course, if one uses a message to add multiple objects, it renders
    > > moot the issue of returning self from the "add single object" message
    > > which is nested to add multiple objects.[/color]
    >
    > I agree.[/color]

    OK...
    [color=blue]
    > If, for instance, for distributed objects, you write a message:
    >
    > - (void) mydistributemessage:a:b { [[self add:a] add:b]; }
    >
    > Then you hopefully agree that there is NO overhead at all associated to
    > the "return self".[/color]

    This, of course, has pretty much nothing to do with the preceding point
    (which you seemed to agree to).

    Let's try thing again.

    Relying on "return self" and using nested messaging to simulated
    Smalltalk style cascaded messages for the example of adding objects to a
    collection is made moot by having a message that adds multiple objects
    to a collection.

    In other words, being able to add a variable number of objects to a
    collection in a single method, removes any concern about the behavior of
    how adding a single object to a collection (which would be a different
    method).

    So rather than slavishly convert Smalltalk's:

    collection add: anObject; add: anotherObject; add: thirdObject.

    to:

    [[[collection add: anObject] add: anotherObject] add: thirdObject]

    it is better to use:

    [collection addObjects: anObject, anotherObject, thirdObject, NULL];

    at which point _it doesn't matter_ if "add:" return self or not (since
    there is a better way to add multiple objects anyway).

    For those scoring along at home, David Stes presented the strawman
    argument that you want "[collection add: anObject]" to return the
    collection _in order to add multiple object_, and since DO returns NULL,
    well, that must be evil and bad.

    It looks like he actually agreed that said strawman isn't actually
    useful (since there were better ways to do it), which invalidates it as
    a reason for DO to be evil and bad.

    Please try again with a useful example of why you want methods to return
    self by default if you want to use that to discredit DO.

  4. Default Re: Returning self instead of void

    David Stes wrote:[color=blue]
    >
    > John C. Randolph <jcr@nospam.idiom.com> wrote:[color=green][color=darkred]
    > >>
    > >> [[myCollection add:myObject] addtherObject];[/color]
    > >
    > > Yes, despite the fact that your example is rather silly.[/color]
    >
    > Why is this silly ?[/color]

    You haven't ever written a project that used distributed objects, have you?

    -jcr

  5. Default Re: Returning self instead of void

    John C. Randolph <jcr@nospam.idiom.com> wrote:[color=blue]
    >
    > You haven't ever written a project that used distributed objects, have you?[/color]

    If you have 3 proxy objects, as in something like:

    [[remoteCollection add:remoteObject] addtherRemoteObject];

    Then "return self" is efficient if it returns the proxy for the receiver.

    Unless of course you are transferring the entire collection (with possibly
    tens of thousands of objects in it) over the network.

    Are you doing the latter ? That would be very silly.


  6. Default Re: Returning self instead of void

    Glenn Andreas <gandreas@no.reply> wrote:[color=blue]
    >
    > Relying on "return self" and using nested messaging to simulated
    > Smalltalk style cascaded messages for the example of adding objects to a
    > collection is made moot by having a message that adds multiple objects
    > to a collection.[/color]

    The issue of making one "big" message as opposed to smaller messages,
    has nothing to do with "return self" but rather with the cost of messaging.

    Remote messaging is expensive, so you may want to write one big message,
    if profiling shows that messaging between processes is too expensive.

    Just as with "return self", the limitations of remote messaging, should not
    imply that for local messaging, you shouldn't use "small" messages.

    It's like saying: remote messages are expensive, please don't write short
    and small messages.

    The guidelines of Apple perhaps include a rule only to write large spaghetti
    code methods with lots of arguments, perhaps because they are afraid that
    small messages pose an overhead for remote messaging ?


  7. Default Re: Returning self instead of void

    David Stes wrote:[color=blue]
    >
    > John C. Randolph <jcr@nospam.idiom.com> wrote:[color=green]
    > >
    > > You haven't ever written a project that used distributed objects, have you?[/color]
    >
    > If you have 3 proxy objects, as in something like:
    >
    > [[remoteCollection add:remoteObject] addtherRemoteObject];
    >
    > Then "return self" is efficient if it returns the proxy for the receiver.[/color]

    Proxies don't travel across the network. Think about it.

    -jcr

  8. Default Re: Returning self instead of void

    David Stes wrote:
    [color=blue]
    > The guidelines of Apple perhaps include a rule only to write large spaghetti
    > code methods with lots of arguments, perhaps because they are afraid that
    > small messages pose an overhead for remote messaging ?[/color]

    It never ceases to amaze me, the absurd things you come up with.

    -jcr

  9. Default Re: Returning self instead of void

    John C. Randolph <jcr@nospam.idiom.com> wrote:[color=blue]
    >[color=green]
    >> The guidelines of Apple perhaps include a rule only to write large spaghetti
    >> code methods with lots of arguments, perhaps because they are afraid that
    >> small messages pose an overhead for remote messaging ?[/color]
    >
    > It never ceases to amaze me, the absurd things you come up with.[/color]

    If you remove "return self" because it hypothetically poses an overhead for
    remote messaging, then you can, following the same absurd logic, also remove
    messages with just one argument, and use only long messages that transfer all
    arguments in one "go" over the network. So you'd have to remove all small
    messages and prefer big messages instead.


  10. Default Re: Returning self instead of void

    John C. Randolph <jcr@nospam.idiom.com> wrote:[color=blue][color=green]
    >>
    >> Then "return self" is efficient if it returns the proxy for the receiver.[/color]
    >
    > Proxies don't travel across the network. Think about it.[/color]

    Think about it yourself.

    If I have three proxy objects and I do:

    [[remoteCollection add:remoteObject] add:remoteOtherObject];

    Does "return self" return the proxy 'remoteCollection' or not ?

    I would expect that it returns the receiver, i.e. the proxy object.

    Therefore 'return self' doesn't travel across the network.


+ Reply to Thread
Page 14 of 24 FirstFirst ... 4 12 13 14 15 16 ... 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