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.
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
There's also the added benefit that you can call params in list context
to get an array containing all the information you have stored in
params() which can make debugging a little bit easier.
I understand that the purpose of the param method is to give me a way to
store 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.
Speaking of which, who wants to take the first stab at
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
From: Andrew Brosnan [EMAIL PROTECTED]
Just speaking generally about OO, I always figure it's dangerous to
monkey with the object's underlying data structure. Might it change in
the future? Who knows.
I agree with that if I'm acessing C::A's underlying data structure. What I'm
getting at is why
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?
It sounds like you want to rewrite the contract. Currently, the contract states
if you use the param method and its implicit get/set
On 7/4/05 at 2:06 PM, [EMAIL PROTECTED] (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
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
I agree with that if I'm acessing C::A's underlying data structure. What I'm
getting at is why does C::A force its underlying data structure upon me?
Shouldn't I be able to access $self any way I want? Shouldn't there be a way
to prevent me from stepping on C::A's data structure without
Mark Fuller wrote:
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
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.
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
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
Following are replies to Dan and Andrew:
From: Dan Horne [EMAIL PROTECTED]
It seems to me that the namespace issue is problematic. ... but what if I
unknowingly wrote a plugin that uses the same attribute,
From what I gather, plug-ins rely upon a namespace mechanism C::A
recommends. Why can't
From: Cees Hek [EMAIL PROTECTED]
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.
If C::A provided the namespace, wouldn't this reduce the chances
15 matches
Mail list logo
