On Sun, 12 Dec 2004 06:23:06 +0900, Ilmari Heikkinen <kig / misfiring.net> wrote:
> la, 2004-12-11 kello 22:38, zuzu kirjoitti:
> 
> > perhaps i don't just want the
> > default STDOUT but would like to specify tty3 versus tty9 or perhaps
> > window7 of some screen tty multiplexing session or how emacs manages
> > buffers, and so on...
> 
> You would then replace STDOUT with e.g. STDERR, or even
> File.open("log","a"){|f| f.puts(string) }

i wouldn't want to save to a file as an intermediary, and then have to
use something like the 'tail' command in another tty...  (for example,
imagine if you were writing a cryptography tool).   but since in unix
"everything is a file", i suppose some way could exist to write to a
tty "file" directly.

though what i am really imagining is something such as a window
manager written in ruby, where the display windows are objects
(instances of a Window class or whatever), and take advantage of
"everything is an object" rather than "everything is a file".  like
naked object or the self language, i would like then for window
objects to say how to display themselves to the screen object.

> > oh, also, correct me if i'm wrong, but method/function argument
> > passing really should only be used for CONSTRAINTS _not_ DATA.
> 
> > and so i also feel that
> >
> >    string.puts(STDOUT)
> >
> > or i'm probably thinking more like
> >
> >    string.puts {STDOUT}
> >
> > much more closely follows the so-called "Principle of Least Surprise".
> 
> string.puts(STDOUT) creates a coupling, the string must call a method of the
> given object with itself as the argument. It must know that the object it's
> passed responds to #puts.

i think to me this seems natural for the pure-OO "everything is an
object" nature of ruby (or  smalltalk).  strings know how to display
themselves, they just need to know where.  again, i think "naked
objects" is the latest way to talk about this, though i often think of
self language which was built on smalltalk.

> Also, string.puts(STDOUT) modifies its argument
> (by printing a new line), which, to me at least, is a big no-no.

i agree that the appending of a newline feels like a no-no.

> STDOUT.puts(string) modifies only STDOUT. It doesn't (shouldn't) magically add
> an extra line to the string. And maybe it's better to have all objects respond
> to just #to_s instead of #puts, #print and #write.
> 
> The postfix notation is tempting though, hmm..
> If you look at unix pipes, they use a syntax like:
> 
> method | method | method , last method taking care of doing things

yes!  yes!  yes!   again, referring to those old emails i had here on
the list with jim weirich, the streams/dataflow/coroutines approach of
pipes and filters (commonly experienced in unix) was my inspiration. 
but this chaining is not at all foreign to ruby, as quite often data
"collects and selects" are performed with method chaining.  e.g.

Object.methods.sort

> The difference to Ruby's method.method.method is that the shell pipes aren't
> namespaced to the preceding object. Ie. With shell pipes it'd be quite doable
> to except the following to work in every situation:
> 
> gets | reverse | puts , because they are in the global namespace. What you pass
> through the pipe doesn't change the available methods.
> 
> In ruby
> 
> gets.reverse.puts
> creates a dependency chain.
> 
> gets must return something that responds to reverse, and reverse must return
> something that responds to puts. Which is bad.

hmmm... is this any different than unix which works blindly in bytestreams?

> So maybe we should emulate
> shell pipes in some other way?
>
> def in; yield self; end
> 
> string.in{|s| STDOUT.puts(s)}
> 
> Works in dataflow-style, too:
> 
> string.in{|s| puts s; s}.reverse.in{|s| puts s}
> 
> Keeps concerns to the objects whom they may concern (String
> doesn't have to know about what methods IO has, etc.), and doesn't do
> black-box modifications to its arguments.
> 
> Comments?

hehe, now i have to dig up those old emails for myself and really put
my brain to work on this.

thanks!!!
-z