Ilya Zakharevich wrote:
>
> The presence of a method STORE is visible outside of the module, and
> may be &required* if the module follows some published (non-Perl) API.
> Variables are of different ilk.
I think you're overlooking they can both be equally visible:
$Foo::DEBUG = 1;
Foo::STORE(5);
depending on how you call them.
> Say,
>
> monk:~->perl -wle '@foo::ARGV = (1..5); print @ARGV'
> Name "foo::ARGV" used only once: possible typo at -e line 1.
>
> So you can have module variables with any names - @ARGV does not get
> in the way of APIs.
That's not really true. Try changing @ISA or @EXPORT_OK. Lots of stuff
changes. And other variables like $_ do get pushed onto you
involuntarily.
I'm sympathetic with your plight, but I don't see a way around it short
of saying something like:
All special Perl 6 variables and subs begin with an
underscore. Anything that begins with an underscore is
reserved for Perl and cannot be declared by the user.
Then changing _every_ Perl special variable and sub:
@_ARGV
%_ENV
%_SIG
_STORE
_FETCH
_DESTROY
And so on. Anything less only fixes part of the problem and destroys
nice consistency within Perl (ALLCAPS == special).
Now what we could say is:
All special Perl variables and subs are in ALLCAPS and
do not contain an underscore. The user cannot declare
non-special variables and subs that follow this pattern.
Then this solves the issue by keeping most of what we have, but
preventing APIs to conflict because they won't be able to:
sub APIMETHOD { }
Attempt to declare non-special ALLCAPS sub at line 1.
$DEBUG = 1;
Attempt to declare non-special ALLCAPS scalar at line 1.
@ARGS = ($stuff, $junk);
Attempt to declare non-special ALLCAPS array at line 1.
But they could still use ALLCAPS stuff as long as there's an underscore
in there somewhere:
sub API_METHOD { }
$_DEBUG = 1;
@ARG_LIST = ($stuff, $junk);
But I don't think "fixing" subs but not variables is the way to go.
-Nate
