The reason for the extra layer of indirection is that
when I wrote it I was thinking that you would tie to
the type of the variable. So you would tie to
Tie::Static::Hash, etc. In fact I am still unsure whether
it is better to always tie to Tie::Static, or to tie to
the actual package that you are blessed into. There is
something to be said for a consistent interface. There
is also something to be said for not violating expectations
about what tied is.
As for the examples you offer of broken ties, read the first
paragraph of "bugs". While it does not offer your examples,
it is clear about the fact that the heuristic uses
package, filename, and line number. Do you think it is
clear enough to warn people away from that map trick?
Personally I am inclined to believe that someone who wants
many tied variables will generally just tie a hash. Do
you think that is wrong? Would it make sense to offer a
function that takes a list of variables and ties them?
Something like this?
sub static {
my $called = join ":", caller();
tie ($_[$_], 'Tie::Static', $called, $_) for 0..$#_;
}
Then people can just call:
static my ($foo, $bar, $baz);
Yes? No? Maybe? | [reply]
[d/l]
[select] |
In fact I am still unsure whether it is better to always tie to Tie::Static, or to tie to the actual package that you are blessed into. There is something to be said for a consistent interface. There is also something to be said for not violating expectations about what tied is.
Well, it's not uncommon to see constructors bless their objects into other classes, so I don't think it's fair for a user to expect that tied return a reference blessed into the original class. Of course, we've seen a few people confused by the former, so it's safe to assume that some people will be confused by the latter.
Do you think it is clear enough to warn people away from that map trick?
I don't think so; it's a subtle bug that's easy for us to spot since we're familiar with the implementation, but for a casual user of the module, it wouldn't be obvious, even after reading through the bugs section. In general, I think one should enumerate the failure modes of a module as much as reasonably possible. I usually find that such documentation helps improve my understanding of a module's internals.
Then people can just call: static my ($foo, $bar, $baz); Yes? No? Maybe?
I really like this, though I'm a confessed syntactic sugar addict. It's much less verbose than the original interface, and nicely abstracts away the whole tied issue from view. The cost is another layer of indirection, though if you're using this module, performance is probably not high on your list of priorities. I also think that static should apply to lists and hashes:
sub static {
my $called = join ":", caller();
my $uniq;
for (@_) {
if (!ref) { tie $_, 'Tie::Static', $called, $uniq++
+ }
elsif (ref eq 'SCALAR') { tie $$_, 'Tie::Static', $called, $uniq++
+ }
elsif (ref eq 'ARRAY') { tie @$_, 'Tie::Static', $called, $uniq++
+ }
elsif (ref eq 'HASH') { tie %$_, 'Tie::Static', $called, $uniq++
+ }
}
}
# usage
static my $foo;
static \ my ($foo, @bar, %baz);
It has also occured to me that there should be a way to properly initialize a static variable. Although one could write:
static my $foo;
$foo = 'blah' unless defined $foo;
The second line could re-initialize $foo after it has been intentionally undef'd. I have some ideas about how to do this, but none of them are very pretty. Any thoughts?
MeowChow
s aamecha.s a..a\u$&owag.print | [reply]
[d/l]
[select] |
