Re: Python vs. Ruby

Sean O'Dell wrote:
> 
> The method print doesn't seem to me to belong, logically, to the string 
> "Hello world", so I don't expect the string to know how to print itself. 
>  It does seem to me to belong as a method of $stdout, however.

There's a series of articles [0] by Alan Holub about writng UI, based on 
the idea that an object should know how to render itself.  In it, Holub 
claims,
[quote]
I'll explain the whys and wherefors in a moment, but here are some rules 
of thumb that you can apply to see if you're really looking at an 
object-oriented system:
  * All data is private. Period. (This rule applies to all 
implementation details, not just the data.)
  * get and set functions are evil. (They're just elaborate ways to make 
the data public.)
  * Never ask an object for the information you need to do something; 
rather, ask the object that has the information to do the work for you.
  * It must be possible to make any change to the way an object is 
implemented, no matter how significant that change may be, by modifying 
the single class that defines that object.
  * All objects must provide their own UI.
[quote]

(Also, see Dave & Andy's discussion [1] of Tell, Don't Ask. )

> 
> I remember back in the early 90's when I first dove into C++, there 
> seemed to be this thought process regarding OOP that went something 
> like: every object should be able to stand alone and interact rarely, if 
> ever, with anything else because that would break the object's 
> encapsulation.  I got that feeling from several texts, and I thought it 
> ludicrous at the time, and still do.  As things have evolved, it seems 
> common sense has stepped in to replace those purist theories, but that 
> article really took me back to that time.

It's true there are countless possible messages one could send  to a 
String object, so having String know about all of them in advance is too 
much.  (There's been a similar discussion on ruby-talk regarding math 
functions)

And while the convention in many langauges has been to pass a String 
object to an IO object, it may be more appropriate to do it the other 
way around, and just call String.print or String.print( someIoObject )

Luckily, it's dead simple to add this to your code by enhancing the 
String class.

class String
   def print( io=$stdout )
     io.puts( self )
   end
end

I've been doing this sort of thing in my code, and after a while it 
struck me as common sense, not purist theory.   I find it goes a long 
way towards cleaning up or avoiding procedural code where I want OO, and 
I find it easier to read.

As Holub states, "I should say that although the foregoing attitude 
might sound extreme, my ideas don't stem from some academic notion of 
purity; rather, every time I've strayed from the straight and narrow in 
my own work, I've found myself back in the code fixing it a month or two 
later. All of this do-it-wrong-then-go-back-and-fix-it work just started 
taking up too much time. It turned out to be easier to just do it right 
to begin with. My notions, then, are based on practical experience 
gathered while putting together working systems, and a desire to put 
those systems together as quickly as possible."

That's pretty much how it's worked for me.


James

[0] http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox_p.html
[1] http://www.pragmaticprogrammer.com/ppllc/papers/1998_05.html


> 
>     Sean O'Dell
> 
> 
>