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 of
colliding with others who may use that namespace? (And maybe reduce the
chance of $self changing and breaking my access to it as
"$self->{__MF__my_var}? If C::A guaranteed that there would always be a
$self->{appl} which could be used as a hash reference, couldn't I safely
access $self->{appl{my_var}}? I'd never have to worry about C::A or a
plug-in using "appl". And, if C:A produced a different object (in the
future), it could still make a hash available for backward compatibility?
It may be six of one, half-dozen of the other. But, it seems to me that C::A
should be the one prefixing all its variables as "__C_A__" so that it is
transparent to the applications extending C:A? If you have the choice
between thousands of users having to prefix their variables, or C:A doing
it, wouldn't it make sense for C:A to do it?
I suppose plug-ins would simply extend the prefix? (__C_A____Plug_in__).
That would be behind the scenes. The person using C::A wouldn't need to know
about it. They could access the hash any way they want?
The next best step (IMO) would be a hash key (like "appl") which is agreed
to never be used by C::A or any plug ins. It wouldn't be as transparent.
But, not as risky as anyone choosing their own prefix (like "__MF__").
Thanks,
Mark
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
