Hey guys,

Long time. I've a question about architecting methods.

As an example, think about how addChild() (or certain other display functions) returns the child DisplayObject that was added. It was really more a choice than a necessity, from Adobe's point of view, to architect it like that, because it isn't necessary for addChild() to have a return value in order to do what it does, or if it did, it could return a Boolean to indicate success or failure. Their choice to architect the display functions this way, however, allows you to write more compact client code, eg.
code:
addToHashTable(addChild(new Sprite));


For some time, I have been questioning whether to write methods this way in my games. For most applications it's unimportant, but for games, I tend to wonder what the time overhead is of adding these "friendly" return values to my methods. If it isn't a primitive return value, then it's just a reference that is passed, and I guess then that overhead only really occurs on the actual line indicating the return, and in the client code there will presumably be overhead only if the return value is actually passed into a property or method to be used.

Ideas? Suggestions? Gifts?