From: zuzu Date: 2004-12-19T01:52:39+09:00 Subject: Re: puts / print as method not keyword? On Mon, 13 Dec 2004 19:52:20 +0900, Martin DeMello wrote: > zuzu wrote: > > > > from a language design perspective, or perhaps this is a ruby idomatic > > / programmer organization behavior perspective, any clues as to why > > nobody uses it? > > Well, one reason could be that there are two separate objects involved > in a display - the object to be displayed and the object doing the > displaying. So you can eiher have object.puts(stdout) or > stdout.puts(object). Then, again, there could be multiple ways for an > object to display itself to various display contexts; the settled-upon > ruby way seems to be a method on the object that tells the context how > to display it, and a method on the context to do the actual displaying. > Thus you'd have svg_canvas.draw(object.to_svg) and > stdout.puts(object.to_s). 'puts object' merely leaves the stdout and the > to_s implicit, but they're both present behind the scenes. > > martin i think this explanation clarifies this matter greatly. also, i think a more elegant solution keeping with current ruby style thus becomes evident. (well, this idea just popped in my head.) for the moment accepting the addition of the Object#| (Object#pipe method), stdout.puts(object.to_s) could then use the syntax: object.to_s | stdout.puts this also more correctly fits the model i was trying to describe than the #display method, and better addresses gavin's concern regarding proper encapsulation (which really is the "one true purpose" of OO; messaging ala smalltalk just happens to be my preferred method-ology). peace, -z p.s. some other insights i've been thinking about w/r/t unix and language design such as perl: 1.) streams (pipes) and regular expressions (filters) are the two breakthrough features / techniques which make unix endure the ages (decades) as a "great" os / programming environment. 2.) "k in k&r" kernighan (most likely) understood this along with "r in k&r" ritchie and ken thompson when first designing unix at bell labs, when kernighan wrote the 'awk' utility. 3.) larry wall designed perl to replace 'awk', afaik, to give regular expressions more of a language behind it (and the shell language debate was never well settled imho, though bash became defacto over csh because C just doesn't scale well as a language, also imho). 4.) what made perl so popular with sysadmins and "scripting" programmers in general, i think, was its emphasis on string / text processing. what i think programmers are really saying here is *stream* processing. except that perl follows unix convention first laid down by ken thompson to follow IO and buffering conventions for data. 5.) ruby as a pure-OO language, by encapsulating data and methods together (at that particular granularity), thus has a significant opportunity to offer not just regular expressions for text processing, but object-oriented (abstracted to any object-type) stream+filter processing. (which i suspect is the first significant step towards truly realizing how OO *really* allows software architecture to scale -- scale-free software design by scale-free ad-hoc programmers.) 6.) or this is all just a bunch of hypothetical mumbo-jumbo which the programming language field is already overflowing with and suitable only as flame-bait, so ignore it. :p p.p.s. for everyone who has brought up the issue of "but the purpose of arguments in functions/methods is to get all of the necessary data into that object/function so that it can do its computation." i also suspect this is a hang-over both from functional programming and from eager-evaluation. thanks to objects and messaging (OO), if properly implemented as late-binding/lazy-evaluation with proper (not shared-state) concurrency, programmers can utilize a timless declarative/constraint programming interface. this then more appropriately follows the original goal of time-shared operating systems (multics / unix) in "maintaining the illusion" that many users have the machine all to themselves rather than preparing batches for processing. (which is just a fancy example of saying people work better when they get feedback interactively.) so in short, throw away your parentheses (as they are traditionally used for methods/functions). most ruby idioms afaik shun method arguments, largely in favor of closures, anyway.