From: Peter Hickman <peter@...>
Date: 2006-12-15T19:02:26+09:00
Subject: Re: Random idea - private, blocks, constants

Daniel Berger wrote:
> The digging could end up happening on the outside, not the inside, and
> that's what I'm trying to avoid.  Say you're in an irb session and you
> want to see what constants are available for the File class.  Normally
> this would just be a handful of values.  If you were to do 'require
> "win32/file"', however, you'll end up with a bunch of function pointer
> declarations showing up in the output that you almost certainly don't
> care about.  It messes up class inspection.
>   

Messy yes but is it a problem? Just open another shell and read the 
documentation.

> Do you object to the existence of private/protected then?  You could
> say the same thing for methods.  As I said, private is advisory only,
> but it does have its uses.  For example, code coverage automation tools
> could be configured to ignore private methods (which is what I'm
> guessing most of them do by default).
>   

Actually I would be quite happy with just public and private, I'm not 
sure that I have ever used protected but I'm willing to accept that 
other people find it useful.

I earn my crust as a Perl programmer and everything is public if you 
used the normal blessed hash technique for objects, Perl objects are 
hack anyway, and guess what - it is not a problem! I realise that for 
anyone from a static background (C/C++/Java/C#) will feel nervous 
without their belt, braces, safety net and lucky rabbit's foot but to be 
honest the problems that all this keyword verbiage protects you against 
is more scaremongering than real. No language, no matter how B&D, will 
stop you from writing bad or broken code. No one will become better a 
programmer because a new keyword is added to the language.