Mark Fuller wrote:
> I understand that the purpose of the "param" method is to give me a way to
> store variables in $self without potentially colliding with C::A's use of
> the same name.
Not just that, but it also provides an easy way to pass variables
between methods as well as communicating between plugins and other base
classes.
> If that's correct, wouldn't it be easier just to choose a naming convention
> within C::A (perhaps a prefix: "__C_A__") and document that users should not
> refer to anything in $self with this prefix? Then I wouldn't have to go
> through the "param" method to safely use store my variables in $self?
That is making the assumption that C::A will always be implemented as a
hash. The documentation says nothing about how C::A is implemented and
therefore makes no guarantees that it won't be an array, or array of
hashes, or anything else.
It's all about good OO encapsulation. And it's even better aesthetically
(at least to most people).
Which looks better/cleaner?
my $stuff = $self->param('stuff');
or
my $stuff = $self->{__C_A__}->{stuff};
> I mean, isn't $self as much mine as it is C::A's? Why should C::A have
> exclusive access to it and force me to use a method to get to it? C::A is
> well-defined with a fixed role. Why can't it namespace itself and let me
> access $self however I want (as long as I stay away from that namespace)?
Well, it is yours in the sense that you are subclassing it, but if you
are using C::A then you *should* only be using the documented interface
since anything else runs the risk of breaking your stuff when you
upgrade. This frees the C::A author(s) from having to maintain their
internals in a backward compatible way. All they have to do is make sure
the interface remains the same. And when you do an upgrade, all you
should have to look at is for API changes in the change log.
Out of curiosity, why don't you like param()? It's a pretty well
established idiom in the Perl community.
BTW, try not to start a new thread in response to a different one ("RFC:
CGI::Application::Plugin::AJAX v0.02" in this case). It really messes up
threaded mail clients and also screws up mailing list archives.
--
Michael Peters
Developer
Plus Three, LP
---------------------------------------------------------------------
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]
