Re: puts / print as method not keyword?

On Mon, 13 Dec 2004 19:52:20 +0900, Martin DeMello
<[e-mail]> wrote:
> zuzu <[e-mail]> 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.