|
in reply to Perl allows package names consisting entirely of colons
Do you consider that the cost of adding the tests to prevent this -- at every place where a package name can appear, at compile time or runtime -- would be worth having, in order to prevent this perfectly logical -- if weird -- possibility?
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP Neil Armstrong |
Re^2: Perl allows package names consisting entirely of colons
by ColonelPanic (Friar) on Nov 27, 2012 at 13:58 UTC
|
I don't think this would not be a significant cost. Only the package declaration would have to be checked (and there is already some checking of package names); everything else would work out to a normal syntax error or a nonexistent package error.
That said, I'm fine with Perl's "if you want to do something stupid, who are we to stop you?" philosophy.
When's the last time you used duct tape on a duct? --Larry Wall
| [reply] |
|
|
::::::::fred = 1;
But also, once you start trying to validate this, what other additional rules are you going to add? Should we allow package _::_::_;?
That said, I'm fine with Perl's "if you want to do something stupid, who are we to stop you?" philosophy.
I also think that we should stick to that principle.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP Neil Armstrong | [reply]
[d/l]
[select] |
|
|
| [reply] |
|
|
Or, you may find yourself painted into a corner, whether through your own brushwork or that of some else, and in need of a quick fix now, pending an extensive redesign to accommodate the required fix in an architected fashion.
All the principles of least surprise and proper encapsulation can -- and should -- be thrown out of the window, when a fix is required now.
Pragmatism over pontification.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP Neil Armstrong
| [reply] |
|
|
|
|
I agree with you in principle, though this particular case is pretty solidly in the "stupid" category. While I wouldn't advocate for all-colon names to be disallowed, I wouldn't shed a tear over it if they did so.
When's the last time you used duct tape on a duct? --Larry Wall
| [reply] |
Re^2: Perl allows package names consisting entirely of colons
by tobyink (Canon) on Nov 27, 2012 at 13:41 UTC
|
I'm not entirely sure what I'd expect. warnings checks (sometimes at compile time, sometimes at run time) and warns about far less weird stuff, at cost.
There would seem to be very little penalty in at least disallowing the package ::::::; syntax the same as package 123 is already disallowed, even if symbols in these packages can still be created by symbol table hackery.
perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
| [reply]
[d/l]
[select] |
|
|
There would seem to be very little penalty in at least disallowing the package ::::::; syntax the same as package 123 is already disallowed,
Forgetting the cost for a moment; why disallow it?
'::' is a separator. Multiple separators with nothing between them imply null namespaces. We allow the null top-level namespace $:: to good effect; albeit that it implies 'main'. Isn't allowing a null namespace at all levels just a logical -- if obscure and unfriendly -- extension of that.
It is perfectly feasible to make the fuel filler mechanisms on cars so that it would be impossible to casually drop a lit match into the tank. We do not do that because whilst it does happen; the occurrence is so rare -- and always deliberate -- that the costs of doing so are disproportionate to the occurrence. Especially when the main source of the occurrence -- the deliberate arsonists, criminals and vandals -- can just as easily adopt some other mechanism to achieve their goals.
For me, it all comes back to the pragmatism that lies at the heart of Perl. If people want to break encapsulation by directly accessing the instance data in objects; Perl doesn't try to stop them. Sure I can use inside out objects; but then "they" can always modify the source code to achieve their goals anyway, so I've imposed the cost of (at least one) extra dereference on every user in order to prevent the occasional perpetrator, who - if their need is sufficient, can still do it any way. And let's face it. Once my module is in their codebase; it is their code. Who am I to place restrictions upon what they need or choose to do with it?
The greatest danger to Perl's continued popularity, and even existence, is the recent obsession to turn Perl away from its pragmatic origins into some theoretically Utopian perfection. Which is impossible, even if it were desirable. Which it isn't.
Expending cycles trying to trap this particular piece of obscurism, when there are so many other possibilities:
{ package _'_'_'_'_; sub hi{ say 'hello from ', __PACKAGE__ } };;
_'_'_'_'_::hi;;
hello from _::_::_::_::_
Just seems pointless.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP Neil Armstrong | [reply]
[d/l]
[select] |
|
|
"why disallow it?"
I never meant to imply that it should be disallowed. I was just expressing surprise that it is not disallowed, given that Perl does place limits on what tokens may appear in a package declaration.
Why disallow package 123 and package 123:: but allow package ::123? The tokens allowed to follow package are have interesting but seemingly arbitrary restrictions, which have nothing to do with what names are actually usable for naming functions, variables, etc...
use 5.010;
use strict qw( vars subs );
use warnings;
# Package name contains whitespace; sub name begins with leading colon
+.
*{"123 :::x"} = sub { say "hello" };
# Yet it can be called.
&{"123 :::x"};
perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
| [reply]
[d/l]
[select] |
|
|
