# from Jonathan Rockway
# on Thursday 19 February 2009 11:20:
>* On Thu, Feb 19 2009, Ovid wrote:
>>The module in question should provide a sub or method to provide
>>access to this data.
This is a good point.
>> Java programmers learned long ago not to let people touch their
>> privates, Perl programmers should learn the same thing.
That's the wrong way to look at it. The way to be civil is not to focus
on protecting *your* privates, but to have a culture where people don't
just go around grabbing things they're not supposed to. The only thing
*one* can do is to refrain from the undesirable behavior with the
understanding that others will do the same.
>This is one of Java's worst design decisions.
This may be true. Still, providing accessors and mutators encourages
them to be used and provides a contract where you won't break things if
they're used properly.
In most places where I've seen private attributes which were private due
to necessity, the issue is actually that there's some assumption being
made about the data with regard to a procedure which spans multiple
method calls or the life of the object. If they're being made private
for safety/paranoia/laziness, that's just a design error or lack of
foresight or lack of features or whatever. Either way, debating the
maintenance hassle of forking vs the maintenance hassle of work-arounds
or monkey patches seems to miss the point that the problem is a library
with the wrong abstraction.
Is there a critic metric for that?
--Eric
--
"But as to modern architecture, let us drop it and let us take
modernistic out and shoot it at sunrise."
--F.L. Wright
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
