From: "Michael Peters" <[EMAIL PROTECTED]>
> 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.
I'm not an OO guru. If I'm off base please forgive me. But, what's the
difference between
$self->param('var_name', 'var_value')
and
$self->var_name = 'var_value'
The only thing I've heard is that I might collide with a var_name C::A uses.
Wouldn't it be simpler to define C::A's variable names such that I would
never collide with them?
> That is making the assumption that C::A will always be implemented as a
> hash.
No. It's my $self, right? So, I can make any assumptions about how *I*
implement myself, right? I subclassed C::A and I don't want to collide (or
*access*) any of *its* variables. I can understand C::A making me use a
setter/getter method to access *its* variables. But, why do I have to use
one to access *my* variables?
That's what I'm driving at. It may be good practice for me to use
setter/getter methods for my own variables. But, why should C::A force me to
use its method?
> Which looks better/cleaner?
> my $stuff = $self->param('stuff');
> or
> my $stuff = $self->{__C_A__}->{stuff};
That's not quite what I was saying. I don't want to access C::A's
hypothetically prefixed variables. What I was saying is that, if they were
prefixed, I wouldn't have to worry about ever accidentally accessing them.
If they were prefixed with __C_A__, I would have the freedom to choose
whether to access $self with a setter/getter method or not. (The idea is
that I *wouldn't* intentionally go around specifying "__C_A__" all over the
place.)
I'm just saying isn't there a way to avoid clobbering C::A's variables
without making me go through C::A's setter/getter method?
> 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
I agree. I'm just saying, couldn't it be documented that C::A's variables
won't be clobbered if I access $self any way I want? Couldn't they be hidden
away differently?
> Out of curiosity, why don't you like param()? It's a pretty well
> established idiom in the Perl community.
Well, on the one hand we hear that Perl's strength is that you can do
something a zillion different ways. :) So, I'm just asking why my $self is
subordinated to C::A's use of it? Isn't there a way for C::A to semi-reserve
its variables from my access and leave it up to me whether I want to access
$self directly or through my own setter/getter methods, or a method C::A
provides?
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?
Thanks!
Mark
---------------------------------------------------------------------
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]
