On 7/4/05, Mark Fuller <[EMAIL PROTECTED]> 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'
>
> 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?
There are a couple of ways of looking at this. Internally, C::A first converts
the keys to UPPER_CASE before performing a lookup or store operation. If C::A
then was to store the variables as object properties (which it doesn't; they're
stored in the _PARAMS object property), you could then be certain that any
properties named in lowercase or in camelCase wouldn't conflict with any stored
using the param() method.
Now, you say, "the only thing I've heard is that I might collide with a var_name
C::A uses". That's not the whole picture. The param() method is called during
object instantiation, and loads any items in the PARAMS key passed to the
constructor. This allows you to customize an application based on the PARAMS
passed in the instance script -- which is pretty powerful. This is my primary
use for the param() method -- application customization. It doesn't really
matter how param() stores the variables; I simply know that they're available
via that method.
> > That is making the assumption that C::A will always be implemented as a
> > hash.
>
> No. It's my $self, right?
I may be reading you wrong, but the variables stored via param() are *not* (at
least last I checked; I haven't downloaded the 4.x series yet) stored in $self;
they're in the $self->_PARAMS hash.
> 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?
It doesn't. You can mix and match. The main purpose of param(), as I noted
above, is to allow the instance script to setup the object environment.
Properties that you don't want controlled in this way don't need to be. For
instance, I often place my database handle in $self->db -- which isn't
accessible via the param() method.
--
Matthew Weier O'Phinney
[EMAIL PROTECTED]
http://weierophinney.net/matthew/
---------------------------------------------------------------------
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]
