On Tue May 12 22:40:00 2015, doy@tozt.net wrote:
Show quoted text> So, one concern I have is, if we are going to allow everything, what about
> stash entries that contain `::`? Right now, Package::Stash->new("Foo::Bar")
> creates %::{Foo}{Bar}, but how would you create %::{'Foo::Bar'}? It seems
> weird to allow everything else except for that.
Perl does not allow you to refer to such entries by any “normal” means (i.e.
symbolic references etc). The only way to get back to them is by lookup in the
stash hash and properly dereferencing the resulting glob value. That’s pretty
useless.
So for most users this will be a trap and/or a nuisance to work around, not
a useful feature. In fact I’m pretty sure that *most* of them will expect to
get `%::{Foo}{Bar}` when they give you `Foo::Bar`.
If you want to ensure the interface is completely regular in case that should
ever be needed, maybe allow passing an arrayref instead of a string, and when
the caller does that, use the elements as nested stash names, verbatim. Then
the answer to your question would be `Package::Stash->new(["Foo::Bar"]`). (And
`Package::Stash->new("Foo::Bar")` or `Package::Stash->new(["Foo","Bar"])` would
be the ways to produce `%::{Foo}{Bar}`.)
But giving someone `%::{'Foo::Bar'}` when they didn’t ask for that in a very
explicit way would be a very shitty default. It is certain to be surprising and
inconvenient to almost every user of the module. Not surprising in the sense of
“I didn’t know it was going to do that” (obviously the behaviour ought to be
documented clearly) but in the sense of “after using Package::Stash for a while
in simple cases and never having to think about that issue, I totally forgot
I had to watch out for that”.
Also, of course: backcompat. (Which is probably the first thing I should have
brought up.) There is already code that uses Package::Stash, which very much
shouldn’t suddenly change meaning. Making people request fully verbatim package
names by way of an arrayref would make it unambiguous what semantics they
expect when passing a string, which would otherwise differ between existing
code and newly written code.
Turns out, though, once you’ve come that far, you can just punt on the matter.
YAGNI etc, since if someone does ever need it, you can then implement the
pass-arrayref-for-fully-verbatim semantics without any break in backcompat. So
there is no need to implement that until the day it’s needed. And that day may
never come.
Does that alleviate your concern?
