Returning self instead of void - Programming Languages

This is a discussion on Returning self instead of void - Programming Languages ; David Stes wrote:[color=blue] > > John C. Randolph <jcr@nospam.idiom.com> wrote:[color=green][color=darkred] > >> > >> No, you offer no solution, but only a limitation.[/color] > > > > Adding the ability to connect to objects in other processes on other > ...

+ Reply to Thread
Page 4 of 24 FirstFirst ... 2 3 4 5 6 14 ... LastLast
Results 31 to 40 of 232

Returning self instead of void

  1. Default Re: Returning self instead of void

    David Stes wrote:[color=blue]
    >
    > John C. Randolph <jcr@nospam.idiom.com> wrote:[color=green][color=darkred]
    > >>
    > >> No, you offer no solution, but only a limitation.[/color]
    > >
    > > Adding the ability to connect to objects in other processes on other
    > > hosts is a limitation?[/color]
    >
    > You haven't solved the problem of using "cascaded" messages with other hosts.
    >
    > As long as you can't use "nested" message sends to remote objects, it seems
    > pretty restricted and a crippled unfinished immature implementation.[/color]

    I can still send nested messages to remote objects:

    id remoteObject1 = [[NSConnection
    rootProxyForConnectionWithRegisteredName:@"foo" host:nil] retain];
    id remoteObject2 = [[NSConnection
    rootProxyForConnectionWithRegisteredName:@"bar host:nil] retain];

    [remoteObject1 doSomethingWith:[remoteObject2 someAccessor]];

    -jcr

  2. Default Re: Returning self instead of void

    Raffael Herzog wrote:[color=blue]
    >
    > John C. Randolph <jcr@nospam.idiom.com> wrote:
    >[color=green]
    > > There is a cost of waiting for that acknowledgement, which is
    > > somewhat
    > > less than waiting for the acknowledgement *and* marshalling a return
    > > value.[/color]
    >
    > But the acknowledgement could simply state: "self has been returned" -
    > no need to unmarshal anything anymore.[/color]

    Not so, since ivars may have changed in the instance on the remote host.
    DO treats all return values the same way, whether it's self, or some
    other object that gets returned.

    -jcr

  3. Default Re: Returning self instead of void

    In article <mail-11D5E7.11133429112003@localhost>,
    Michael Ash <mail@mikeash.com> wrote:
    [color=blue]
    > In article <ESZxb.49718$Zt1.1608841@phobos.telenet-ops.be>,
    > David Stes <stes@D5E02895.kabel.telenet.be> wrote:
    >[color=green]
    > > As long as you can't use "nested" message sends to remote objects, it seems
    > > pretty restricted and a crippled unfinished immature implementation.[/color]
    >
    > I realize this may be difficult for you to grasp, but there is a simple
    > algorithm for transforming nested sends to non-nested sends. For
    > example, the sequence of:
    >
    > [[[obj foo] bar] baz]
    >
    > Becomes:
    >
    > [obj foo];
    > [obj bar];
    > [obj baz];
    >
    > There, that wasn't so hard, was it?[/color]

    Also important is that this makes clear that 'obj' is the receiver of
    all these messages, whereas you have to chase the message sends in the
    first case to find this out.

    Smalltalk has the ; to indicate multiple sends to the same receiver:

    obj foo; bar; baz.

    So the implicit 'self' return isn't used there.

    Marcel

  4. Default Re: Returning self instead of void

    John C. Randolph <jcr@nospam.idiom.com> wrote:
    [color=blue]
    > Raffael Herzog wrote:[color=green]
    >>
    >> But the acknowledgement could simply state: "self has been
    >> returned" -
    >> no need to unmarshal anything anymore.[/color]
    >
    > Not so, since ivars may have changed in the instance on the remote
    > host.
    > DO treats all return values the same way, whether it's self, or
    > some
    > other object that gets returned.[/color]

    Well, of course it depends on how DOs are implemented, maybe I'm just
    too much into Java. But why should the whole object with all ivars be
    (un)marshalled? A stub for the remote object is perfectly enough. If
    self is returned, it's guaranteed that the client already has the
    correct stub, so it (the stub) doesn't need to be serialized to the
    client again, but setting a flag in the acknowledgement does the job
    just fine.

    Or am I on the completely wrong track?

    cu,
    Raffi (new to ObjC)

    --
    Neu im Usenet? Fragen? -> [url]http://www.use-net.ch/usenet_intro_de.html[/url]

    Raffael Herzog - [email]herzog@raffael.ch[/email] - [url]www.raffael.ch[/url] - ICQ #67961355

  5. Default Re: Returning self instead of void

    Raffael Herzog <devnull@raffael.ch> wrote:[color=blue]
    >
    > maybe I'm just too much into Java.[/color]

    No, you're not.
    [color=blue]
    > Or am I on the completely wrong track?
    >
    > cu,
    > Raffi (new to ObjC)[/color]

    You are on the right track.

    In fact, this has nothing to do with ObjC versus JAVA.

    Good programmers can implement things in both ObjC and Java, in a sensible
    way. A certain "programming style" is what you get, regardless of the language.

    Of course, the reverse is also true; "bad" programmers will produce bad
    solutions, whether it is in Objective-C or Java.

    The crippled distributed objects that is not even able to deal with cascaded
    messages, is one such example.


  6. Default Re: Returning self instead of void

    In article <8R2yb.50674$wt1.1579120@phobos.telenet-ops.be>,
    David Stes <stes@D5E02895.kabel.telenet.be> wrote:[color=blue]
    > Good programmers can implement things in both ObjC and Java, in a sensible
    > way. A certain "programming style" is what you get, regardless of the
    > language.[/color]

    You mean like exceptions?
    [color=blue]
    > Of course, the reverse is also true; "bad" programmers will produce bad
    > solutions, whether it is in Objective-C or Java.[/color]

    You mean like subclassing Color from String?

  7. Default Re: Returning self instead of void

    In article <8R2yb.50674$wt1.1579120@phobos.telenet-ops.be>,
    David Stes <stes@D5E02895.kabel.telenet.be> wrote:
    [color=blue]
    > The crippled distributed objects that is not even able to deal with cascaded
    > messages, is one such example.[/color]

    So, uh, have you implemented a DO system? All I can find on your page is
    this precompiler, and a bar chart generator.

  8. Default Re: Returning self instead of void

    David Stes <stes@D5E02895.kabel.telenet.be> wrote in message news:<nDqxb.46553$rt1.1574013@phobos.telenet-ops.be>...[color=blue]
    > Normally, in Objective-C you also "return self".[/color]

    As usual, this depends on the class library you're using. Cocoa, for
    instance, does _not_ use the 'return self' convention.
    [color=blue]
    > This is very convenient as it allows you to "cascade" (nest) messages,[/color]

    'cascading' and 'nesting' are actually different things. 'Nesting' is
    the general ability to have one message-send expression inside
    another, sich that the return value of the inner message-send can be
    used by the outer message-send expression as the receiver or as one of
    the actual arguments. For instance,

    [[aCollection objectAtIndex:14] fooWithBar:[Bar bar]];

    uses nested messages.

    'Cascasing' is the specific concept of sending multiple messages to
    the same object, without having to specify the object itself more than
    once. In Smalltalk, there is a special syntax for this: What would be
    expressed without cascading as

    anObject foo.
    anObject bar.
    anObject fubar.

    can be done using Smalltalk's cascading message-send syntax as

    anObject foo; bar; fubar.

    The semicolons (';') separate the different message-sends, but also
    signify that the next message-send should go to the same receiver as
    the previous one, _not_ to the object that was _returned_ from the
    previous message.
    [color=blue]
    > as in :
    >
    > [[[myObject foo] bar] fubar];[/color]

    Objective-C doesn't actually _have_ cascading messaging, so this is
    how one might in Objective-C try to use nested message-sends to
    emulate Smalltalk's cascading messages. This relies on each method
    returning the original receiver of the message, essentially doing
    'return self', which means that the return value from such a
    message-send can be used as the receiver for another message-send,
    which should result in that message being sent to the same object.

    It may be 'convenient', but it actually somewhat dangerous. That
    sequence of message-sends relies on every message returning 'self', in
    order for those messages to all be sent to 'myObject'. Now consider
    what happens if the 'bar' method gets changed slightly so that it
    might return a different object - now it is that different object that
    gets the 'fubar' message sent to it! Or consider what might happen in
    the case of using a wrapper object, i.e., one that passes some of its
    messages on to another object. Obviously, all the messages _should_ go
    to the wrapper object - but of the wrapped object 'returns self', then
    the wrapper object would have to inspect every value returned from its
    wrapped object and replace any 'self' pointers, and all just to
    support this 'convenience'.

    In the absence of an explicit message cascading syntax, it's a lot
    safer to send each message explicitly to the object you want to
    receive the message:

    [myObject foo];
    [myObject bar];
    [myObject fubar];

    In this case, if the 'bar' method were to change which object it
    returns, there will be no change in the behaviour of the program.
    Likewise a 'wrapper' object doesn't need to worry about the wrapped
    object returning self and thus 'breaking through the wrapper'.

    Even better, if the original ber method were declared as -(void)bar;
    then it would be immediately
    obvious that the updated method -(id)bar; had different semantics,
    which thus gives the entire system (developer, compiler, etc) an
    immediate clue that something has changed.

    I consider it to be simply good practice to use the most precisely
    describing argument and return types that match what a function or
    method is taking as arguments and returning. If a method doesn't
    return a value of its own, to me that makes 'void' the most
    appropriate return type for that method.

    Returning 'self' from such methods instead of 'void' is one of those
    things that may seem convenient at the time, but which in the long run
    just turn out to add complications and have other repercussions that
    weren't thought of. Such as the addition of unnecessary overhead in a
    distributed-object environment - where suddenly, returning a reference
    to an object is a significantly more costly operation than returning
    nothing (whereas within the same machine, the performance difference
    is negligible).

    So on the one hand we have the 'convenience' of being able to cascade
    messages to the same object, which can be done just as easily by just
    writing each message send separately and spelling out the same object
    explicitly; and on the other hand we have significant performance
    implications.
    [color=blue]
    > At some point, Apple had the idea to change their classes to not return
    > self, and they wrote a script to change all their "return self" statements
    > and delete them, and slap a (void) in front of their method declarations.[/color]

    Oh? Can you please identify this script and post a precise reference
    to this script?

    Of course he can't, because such a script is a figment of David Stes'
    imagination. NeXT did write scripts to ease the transition of code
    from using the NeXTStep classes to using the OpenStep ones, but the
    NeXTStep classes themselves weren't changed - they were left as they
    were, so that existing code would contunie to work unchanged. Instead,
    OpenStep introduced a new, separate, parallel class hierarchy
    precisely so that the two could be intermingled with impunity. So
    while neXT did adopt a different convention in OpenStep than they had
    used in NeXTStep, that's a far cry from what David Stes claims above.
    [color=blue]
    > I suspect they did this, because at the time they introduced their memory
    > management (where the +new messages were replaced by their +alloc/autorelease
    > stuff)[/color]

    NeXT used +alloc/-init even before they introduced the OpenStep
    classes; and +new is still available, as

    +new { return [[self alloc] init]; }

    which offers the same functionality, but is simply implemented on an
    OO substrate rather than directly on a C-based one.
    [color=blue]
    > they wanted to simplify their "reference" count rules by having less
    > objects (return values) exchanged between sender and receiver of messages.[/color]

    The reference counting rules are not affected by whether a method
    returns 'self' or not. If David Stes had actually understood Cocoa's
    reference counting, he would know this - but either he _hasn't_
    understood, or he is deliberately trying to spread FUD.

    Best wishes

    // Christian Brunschen

  9. Default Re: Returning self instead of void

    Christian Brunschen <cb@df.lth.se> wrote:[color=blue]
    > David Stes <stes@D5E02895.kabel.telenet.be> wrote in message news:<nDqxb.46553$rt1.1574013@phobos.telenet-ops.be>...[color=green]
    >> Normally, in Objective-C you also "return self".[/color]
    >
    > As usual, this depends on the class library you're using. Cocoa, for
    > instance, does _not_ use the 'return self' convention.[/color]

    The part that has problems with 'return self' is, according to J.Randolph
    of Apple, their remote messaging.

    For local messaging, it probably is still OK to use 'return self', although
    that you have the problems of 'ownership' (with their release/retain stuff).

    So assuming that in a future version of remote messaging, the current
    limitation (it doesn't support 'return self' yet) is lifted, 'return self'
    will work again in the future.


  10. Default Re: Returning self instead of void

    In article <R1pyb.52993$DJ2.1693825@phobos.telenet-ops.be>,
    David Stes <stes@D5E02895.kabel.telenet.be> wrote:
    [color=blue]
    > For local messaging, it probably is still OK to use 'return self', although
    > that you have the problems of 'ownership' (with their release/retain stuff).[/color]

    No you don't. You've been told this repeated. It has been explained
    ad-naseum. Yet you continue to spout these falsehoods. Why?

+ Reply to Thread
Page 4 of 24 FirstFirst ... 2 3 4 5 6 14 ... 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