[Wellington-pm] A question about scopes

[Jacinta Richardson]

Cliff Pratt wrote:

>>private methods rely on programmers behaving because it's polite, not
>>because you force them to do so.  There's some quote here about a
>>shot-gun, but I can't remember it off the top of my head.  This would
>>apply too to private subs. After all, the programmer usually has
>>access to your source code when they "use" your module, so they can
>>break any strictures you set up anyway.
>>
> 
> True. Even with a compiled program it can be decompiled. Politeness is
> fine, but to some extent you might want to hide some of the workings of
> your object. An object is *supposed* to be opaque, isn't it.

In theory yes, in practice; less so.  Consider a database handle from DBI or a
UserAgent from LWP or a WWW::Mechanize object.  Most people use these every day
without ever reading more than the documentation of the API.  For these uses
these object could be built on the traditional hash structure, or with a rarer
array base.  They could even be built as an inside out object; the programmer
doesn't and shouldn't have to care.  They could have bazillions of "helper"
private functions, or none, the users probably won't even open the source code
to see.

However, sometimes people want to do unusual things - like debug strange
behaviour.  Perhaps someone wants to subclass DBI in order to ensure certain
triggers are called before any execute.   This might involve a lot of looking at
the code, and of writing their own methods to supplant the ones you wanted to be
private.

In a case for me today, I wanted WWW::Mechanize to let me "tick" every checkbox
of a given name.  The standard API didn't work in the way I needed, so I
Data::Dumped the object, played around with a few ideas and found a cheaty way
of doing it.  Personally I think either the documentation is wrong, or it's a
bug that I couldn't do it the only obvious way, but regardless that didn't solve
the problem *now*.

Should the object have remained opaque?  Theoretically yes, in practice that
wouldn't have been useful to me.  If I didn't have access to the details of the
object I would have had to parse the HTML to get what I wanted.  Is this code
likely to break horribly on me sometime in the future when the data structure
changes?  Absolutely!  Will that be a problem?  Probably not by that time.  Good
programmers should be able to weigh up the pros and cons of abusing the
internals of your classes.  They should understand that side-stepping the API
means they deserve all they get.  Yet akin to that, if you're hiding *useful*
stuff in your class which is not documented in your API then you should expect
people to use it all the same and blame you when it changes.

All the best,

	Jacinta

-- 
   ("`-''-/").___..--''"`-._          |  Jacinta Richardson         |
    `6_ 6  )   `-.  (     ).`-.__.`)  |  Perl Training Australia    |
    (_Y_.)'  ._   )  `._ `. ``-..-'   |      +61 3 9354 6001        |
  _..`--'_..-_/  /--'_.' ,'           | contact at perltraining.com.au |
 (il),-''  (li),'  ((!.-'             |   www.perltraining.com.au   |