|Syntactic Confectionery Delight|
Re: Re (tilly) 2: Tie::Staticby MeowChow (Vicar)
|on Jul 15, 2001 at 14:25 UTC||Need Help??|
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:
It has also occured to me that there should be a way to properly initialize a static variable. Although one could write:
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