Mark Fuller wrote:
> 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'
Well, first off, you can't do the second one. It would only work if you
made a method named 'var_name' that would act like a setter/getter (or
use the :lvalue method attribute). So you would need to compare
$self->param(var_name => 'var_value')
to
$self->{var_name} = 'var_value';
It's basically the difference between using a hashref and using an
object. If you have an object, then why not use OO? If all you have is a
hash, then by all means use it as a hash. But that's not what you have.
> 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?
C::A never putts anything in param(). It's just for your use.
>>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?
No, that's just it. By using C::A as a base class, the $self is what
C::A decides it is, not you. The only way you could decided fo yourself
is to use a 'HAS A' (delegation) relationship with C::A, not an 'IS A'
(inheritance) and that would be extremely messy.
> 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?
C::A only forces you because you chose to use it as your base class.
> 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.)
Once again, *C::A doesn't put anything into param()*. It's just for your
use. Where it puts it's own variables is it's own business.
> 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?
Well, that's sort of the point of documenting the interface is that you
don't document the internals. They are no ones business but the author's.
> 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 agree that there is usually more than one way to do it. That doesn't
mean that there's more than one 'right' way to do it :) And it also
means that modules authors don't have to provide more than one.
If you want to store your stuff in the $self blessed hash, then go ahead
and do it. But why should the C::A author change his interface and
document his internals when there is already a provided way to do it?
--
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]
