> I'm not arguing whether setter/getters are good or bad. Just why I'm forced
> to use C::A's. Why is that the only way to avoid stepping on C::A's
> variables?
It sounds like you want to rewrite the contract. Currently, the contract states
"if you use the param method and its implicit get/set method then we promise not
to screw you up when you upgrade CGI::App to a new version."
What you want it "CGI::App promises to put its own variables in
$self->{__somewhere_over_the_rainbow_*}, so if you want to put your variables in
the $self->{_my_dad_can_beat_up_your_dad_*} namespace then you can do that and
you're fine."
The argument against this is basically that the contract you want makes the
CGI::App authors promise to give you an underlying hashref implementation. That
may not make sense in the future. It almost certainly won't make sense in a
Perl 6 world (as Michael Graham was kind of getting at in his earlier email
along these lines).
This whole great divide is just one of the underlying premises behind
object-oriented programming -- module (well, class) authors are responsible to
module (well, class) users in terms of functionality, but not in terms of how it
achieves the functionality. In almost any other mainstream language other than
Perl no-one would ever want to try to do what you want, nor would they even
*contemplate* being able to do this, because the underlying implementation is so
opaque to derived classes that there's basically no way to get at the underlying
data structure.
In Perl 5 the underlying data structure is *so* close to the interface that
module users *always* want to be able to do this, and then their scripts
*always* break when they upgrade to the latest version of the module because the
module author changed something.
Cheers,
Richard
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
