Returning self instead of void - Programming Languages

This is a discussion on Returning self instead of void - Programming Languages ; In article <j1nCb.74502$ru4.2979993@phobos.telenet-ops.be>, David Stes <stes@D5E02895.kabel.telenet.be> wrote: [color=blue] > Glenn Andreas <gandreas@no.reply> wrote:[color=green] > > > > But if the remote system does a "return self" [...] > > it definitely more expensive than not returning anything[/color] > > Compare ...

+ Reply to Thread
Page 23 of 24 FirstFirst ... 13 21 22 23 24 LastLast
Results 221 to 230 of 232

Returning self instead of void

  1. Default Re: Returning self instead of void

    In article <j1nCb.74502$ru4.2979993@phobos.telenet-ops.be>,
    David Stes <stes@D5E02895.kabel.telenet.be> wrote:
    [color=blue]
    > Glenn Andreas <gandreas@no.reply> wrote:[color=green]
    > >
    > > But if the remote system does a "return self" [...]
    > > it definitely more expensive than not returning anything[/color]
    >
    > Compare this to local messaging.
    >
    > 'return self' takes a few instructions. But so does local message lookup.
    >
    > So 'return self' takes a small percentage, say 2% of the time.
    >
    > In the remote case, sending the message over the network takes many thousands
    > of instructions.
    >
    > Now how does that compare with the cost of 'returning the proxy on the client
    > side'.
    >
    > I think the time of 'return self' may be well less than 2%.[/color]

    OK, here's a simplist example. Assume that sending something across the
    network has a 50ms latency (disregarding any additional handshaking,
    acks, etc...), and that any actual code is 1ms to execute.

    [[aCollection add: anObject] add: anotherObject];

    is converted to:

    0 local sends "aCollection add: anObject", waits for return value
    50 remote recieves "aCollection add: anObject", performs it
    51 remote returns self (aCollection)
    101 local receives value of "[aCollection add: anObject]" (i.e.
    aCollection)
    102 local sends "(aCollection) add: anotherObject", waits for
    return value
    152 remote receives "(aCollection) add: anotherObject", perorms it
    153 remote returnes self (aCollection)
    203 local recieves result (and returns it from proxy, which is
    ignored)
    204 local executes next statement


    vs:

    [aCollection add: anObject; add: anotherObject]
    (where the compiler knows now that "add" returns void

    0 local sends "aCollection add: anObject", doesn't wait
    1 local sends "aCollection add: anotherObject", doesn't wait
    2 local executes next statement
    50 remote recieves "aCollection add: anObject", performs it, does
    nothing more
    51 remote recieves "aCollection add: anotherObject", performs it,
    does nothing more

    When "self" is returned, it is 204 ms to execute on the local side, when
    it is declared void, its 2 ms.

    The point is that returning _anything_ (and add: could return the object
    added and it would take the same amount of time) requires waiting for
    the message to be sent and responded to, while if it is declared as not
    returning a value, it can be executed and then continued.

  2. Default Re: Returning self instead of void

    Glenn Andreas <gandreas@no.reply> wrote:[color=blue]
    >
    > The point is that returning _anything_
    > requires waiting for the message to be sent and responded to[/color]

    If I do this on the server:

    [[localCollection add:localObject] addAlltherLocalCollection];

    Then I should get the same result, as after doing this on a client:

    [[remoteCollection add:remoteObject] addAlltherRemoteCollection];

    This is very important if these collections are "Ordered" (OrdCltn).

    Obviously, if remote messaging doesn't "wait" for messages to finish one
    after another, then the order in which elements are added to an OrdCltn will
    be different, in the local and remote case.

    This is therefore not at all an argument to remove "return self".


  3. Default Re: Returning self instead of void

    In article <gFpCb.74808$tu4.2982043@phobos.telenet-ops.be>,
    David Stes <stes@D5E02895.kabel.telenet.be> wrote:
    [color=blue]
    > Obviously, if remote messaging doesn't "wait" for messages to finish one
    > after another, then the order in which elements are added to an OrdCltn will
    > be different, in the local and remote case.[/color]

    That's not obvious at all. Waiting for a response and maintaining
    ordering are two completely separate things. Forget DO for a minute, do
    you even know how TCP works?

  4. Default Re: Returning self instead of void

    Michael Ash <mail@mikeash.com> wrote:[color=blue]
    >
    > Forget DO for a minute, do you even know how TCP works?[/color]

    DO seems to work more like UDP: you send a message, and it seems to be
    implemented as a datagram.

    The message is dispatched, but apparently you cannot hope to get back 'self'.


  5. Default Re: Returning self instead of void

    Glenn Andreas wrote:
    [color=blue]
    >
    > [aCollection add: anObject; add: anotherObject]
    > (where the compiler knows now that "add" returns void
    >
    > 0 local sends "aCollection add: anObject", doesn't wait
    > 1 local sends "aCollection add: anotherObject", doesn't wait
    > 2 local executes next statement[/color]

    Wouldn't many(most) cases require a sync here? It is of course still
    faster...

    Also, how does local know there was no failure to send commands and that
    the remote end was able to execute those commands? Certainly there must
    be some further stuff going on underneath the Proxy abstraction in order
    to verify communications.

    NR


  6. Default Re: Returning self instead of void

    Noah Roberts <nroberts@dontemailme.com> wrote:[color=blue]
    >
    > Certainly there must
    > be some further stuff going on underneath the Proxy abstraction in order
    > to verify communications.[/color]

    If not, the Apple DO could be renamed to UDO : Unreliable Distributed
    Objects.


  7. Default Re: Returning self instead of void

    In article <kNpCb.74819$kv4.2996268@phobos.telenet-ops.be>,
    David Stes <stes@D5E02895.kabel.telenet.be> wrote:
    [color=blue]
    > Michael Ash <mail@mikeash.com> wrote:[color=green]
    > >
    > > Forget DO for a minute, do you even know how TCP works?[/color]
    >
    > DO seems to work more like UDP: you send a message, and it seems to be
    > implemented as a datagram.
    >
    > The message is dispatched, but apparently you cannot hope to get back 'self'.
    >[/color]

    You can get any return value you have declared - if it is declared as
    "void", you, of course, don't get anything back. It's a "void" after
    all.

    If it is declared as "id" then you get something back, and you have to
    wait for it to come back before proceeding (since the local calling code
    never knows for sure what will come back).

    There is no problem you keep whining about. If you want something, you
    get it but you have to wait. If you don't need it, you shouldn't have
    declared it as returning a value, and you don't need to wait then.
    "Void" does not causing things to suddenly fly backwards in time or
    anything.

  8. Default Re: Returning self instead of void

    In article <vtkaqg3hu9s8ef@corp.supernews.com>,
    Noah Roberts <nroberts@dontemailme.com> wrote:
    [color=blue]
    > Glenn Andreas wrote:
    >[color=green]
    > >
    > > [aCollection add: anObject; add: anotherObject]
    > > (where the compiler knows now that "add" returns void
    > >
    > > 0 local sends "aCollection add: anObject", doesn't wait
    > > 1 local sends "aCollection add: anotherObject", doesn't wait
    > > 2 local executes next statement[/color]
    >
    > Wouldn't many(most) cases require a sync here? It is of course still
    > faster...
    >
    > Also, how does local know there was no failure to send commands and that
    > the remote end was able to execute those commands? Certainly there must
    > be some further stuff going on underneath the Proxy abstraction in order
    > to verify communications.[/color]


    Obviously these sorts of concerns need to be addressed by the
    implementation - and I wasn't trying to explain the exact details of how
    DO (or any other remote messaging system) worked, but rather try to make
    a simple example (and I explcitly mentioned disregarding handshaking,
    etc...).

    These sorts of issues would even be applicable to the single system
    threaded case as well, if you wanted to send messages between threads.
    Of course, talking about exception handling, multi-threading, and using
    a distributed objects scheme to implement that would probably just cause
    the Stes-Bot to enter spew mode...

  9. Default Re: Returning self instead of void

    In article <vtkaqg3hu9s8ef@corp.supernews.com>,
    Noah Roberts <nroberts@dontemailme.com> wrote:
    [color=blue]
    > Glenn Andreas wrote:
    >[color=green]
    > >
    > > [aCollection add: anObject; add: anotherObject]
    > > (where the compiler knows now that "add" returns void
    > >
    > > 0 local sends "aCollection add: anObject", doesn't wait
    > > 1 local sends "aCollection add: anotherObject", doesn't wait
    > > 2 local executes next statement[/color]
    >
    > Wouldn't many(most) cases require a sync here? It is of course still
    > faster...
    >
    > Also, how does local know there was no failure to send commands and that
    > the remote end was able to execute those commands? Certainly there must
    > be some further stuff going on underneath the Proxy abstraction in order
    > to verify communications.[/color]

    There certainly is more than just the proxy. There is a connection
    underneath it all which handles a lot of details. Proxies just ask the
    connection to transmit data, they don't know how it all works.

    The quoted code should never require a sync if aCollection exists on the
    other side. It's not necessary to wait for a response to ensure that
    everything happens in the right order. When we finally getting around to
    sending a message to aCollection that requires a response, the DO system
    will wait until the response comes back. If for some reason one or both
    add: messages has not yet been executed, it will also wait for those to
    finish.

    The connection will also handle communications failures by possibly
    throwing an exception, and posting a notification. It doesn't matter if
    we don't find out right away that the add: message failed and the
    program goes on to do other things; when it tries to get return value
    for something, the failed connection will become immediately clear.

  10. Default Re: Returning self instead of void

    In article <kNpCb.74819$kv4.2996268@phobos.telenet-ops.be>,
    David Stes <stes@D5E02895.kabel.telenet.be> wrote:
    [color=blue]
    > Michael Ash <mail@mikeash.com> wrote:[color=green]
    > >
    > > Forget DO for a minute, do you even know how TCP works?[/color]
    >
    > DO seems to work more like UDP: you send a message, and it seems to be
    > implemented as a datagram.
    >
    > The message is dispatched, but apparently you cannot hope to get back 'self'.[/color]

    Sorry, but you're clueless.

    DO on Cocoa can work on either Mach ports or TCP. The transport that the
    messaging system uses doesn't affect the fact that the messaging system
    itself is capable of dispatching messages and not blocking the program
    until a reply comes back. It is also capable of blocking the program if
    it needs to wait for a reply, like if a return value is expected.

    DO works. It is nearly perfectly transparent. I'm writing some DO code
    right now. It's very nice. You should try it, instead of ranting about
    things which you know *nothing* about.

    Have you done any network programming at all? Anything, ever? You set
    yourself up as some god-like expert, but it becomes more and more
    apparent that you're helpless beyond writing a precompiler.

+ Reply to Thread
Page 23 of 24 FirstFirst ... 13 21 22 23 24 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