1) Why do ST methods return "self" if nothing is explicitly returned?
Blue book talks of: *extent: newExtent* corner <- origin + newExtent *Bytecode:* Rectangle extent: 0 push the value of the receiver's first instance variable (origin) onto the stack 16 push the argument (newExtent) onto the stack 176 send a binary message with the selector + 97 pop the top object off of the stack and store it in the receiver's second instance variable (corner) *120 return the receiver as the value of the message (extent:)* For blocks: "Since a block's expressions may not have been evaluated when it returns from fork, the value of fork must be independent of the value of the block's expressions. A block returns itself as the value of fork." also: http://www.mirandabanda.org/bluebook/bluebook_chapter28.html#ReturnBytecodes28 Semantically in a pure OOPS land sending a message to an object returning a nil / void may seem not so object oriented either. Message modifies or actions something on the object, the default return of the object seems sensible option to return nil Facilitates I believe the easy operation of chaining method sends without each time having explicitly to return the object in each of those methods. viz: Aircraft airforceOne flyToDestination haltForRefuelling returnToStation. or its other forms with bracketed keyword messages. Though using cascades one can do similar stuff but will read less english like. 2) In Collections, why does "add:" return the object being added, and not "self"? Blue Book: "Note that the add: and remove: messages answer the argument rather than the collection itself so that computed arguments can be accessed." I have always pondered why this is essential and returning the collection would be fine..or return true / false rather than argument / exception, infact for Set new add: 2; add: 2 . will return 2.. though the second one does not add anything to the Set. On Thu, Dec 27, 2012 at 6:02 AM, Sebastian Nozzi <[email protected]> wrote: > Hello Smalltalkers, > > I was interacting the other day with an user in a Scala mailing list, > and he had some questions about Smalltalk. From his FP (functional > programming) point of view there were some things that looked strange. > I tried to reply to the best of my ability, but still I don't really > know the background for these design decisions. So I come to you, real > experts, hoping for some answers. > > The questions were: > > 1) Why do ST methods return "self" if nothing is explicitly returned? > (he would have expected something like "Unit" in Scala, or "Void" - > which I know makes little sense in a world like ST's, so I didn't > include this in the Stackoverflow question) > > > http://stackoverflow.com/questions/14047887/why-do-methods-return-self-by-default-in-smalltalk > > 2) In Collections, why does "add:" return the object being added, and > not "self"? > > > http://stackoverflow.com/questions/14047940/why-does-add-return-the-object-added-in-smalltalk-collections > > ---- > > The original interaction in the Scala mailing list (nice language, by > the way) was here: > > https://groups.google.com/d/topic/scala-user/gPEJNAEZO-8/discussion > > > Thanks a lot in advance! > > > Sebastian > >
