On 7/4/05, Mark Fuller <[EMAIL PROTECTED]> wrote:
> From: "Michael Peters" <[EMAIL PROTECTED]>
> > If you want to store your stuff in the $self blessed hash, then go ahead
> > and do it.
>
> Wait. That sounds like what I'd like to do. Is there a way I can bless my
> own sliver of $self and store my own data structure there without trampling
> on C:A's use of $self (and without being required to use its method to
> access its data strcuture)? Can I have my own data structure?
>
> I'm sorry I stirred up such a discussion. It's probably my ignorance.
No need to be sorry. You didn't stir anything up. What you did is
start some healthy discussion, and I think it has turned into a
discussion that many people can learn from.
I hear you when you say you just want to use $self and do with it what
you want. Personally I think it is often OK, as long as you know all
of the pitfalls that come with it, so that you will not be surprised
when it breaks down in front of your eyes. Really there are only two
main concerns:
1. You need to make sure that you use your own namespace so as not to
collide with anyone else. You suggested that CGI::App use __C_A__ as
a prefix, but it really should be you that uses a prefix. Perhaps
__M_F__ to use your prefix style. There is a good chance that no one
else (plugin authors and such) will use that prefix. So if you access
it directly, use $self->{__M_F__var1} or $self->{__M_F__}->{var1}
2. The author of CGI::Application may decide that $self is no longer
going to be a hashref, and instead is going to use inside-out objects,
or an arrayref or something else. This is the one that everyone
always brings up. I would like to state that this is almost never
going to happen (I know, famous last words). But it is important to
know that it can happen, which means you need to be more careful about
upgrading to new versions of CGI::App. That is a tradeoff you have to
make.
You have another option as well that could work for you, and would be
implemented cleanly and wouldn't throw up any red flags. Create
accessors for all your variables and have these accessors use the
->param method.
# Custom param method to hide the new namespace
sub my_param {
my $self = shift;
my $key = shift;
my $value = shift;
$self->param('__M_F__'.$key => $value) if defined $value;
$self->param('__M_F__'.$key);
}
sub var1 {
my $self = shift;
return $self->my_param('var1' => @_);
}
sub var2 {
my $self = shift;
return $self->my_param('var2' => @_);
}
Then you can access them like this:
my $var = $self->var1;
$self->var1('new value');
I'm sure you could improve upon that in some way, but at least it
shows a way that will allow you to easily add your own parameters to
your subclass without needing to worry about the underlying
architecture.
Of course you can choose to ignore all the advice on the list as well,
and just access $self directly (I have been known to do it as well).
It is really up to you. Just make sure you know the consequences of
those decisions.
Cheers,
Cees
---------------------------------------------------------------------
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]
