in reply to Re: Why would you use our?
in thread is use strict a compile time directive?

I never had a problem with vars in the first place. The internals may be a hack, but I am perfectly happy with the external interface.

I guess I haven't really seen the point of the associated types feature. I mean I understand it, but the amount of work that I need to do to get a modest optimization is enough that I don't want to bother. Plus I work in a job where we may have a number of people who are pretty good at Perl, but that is because they learned on the job. And the associated types feature is one feature more than I really want people to maintain. (After all I start with people who have not been exposed to when to use hashes, and take them through OO, anonymous functions, etc. That is already quite a lot.)

So no, package access to a feature I don't use isn't a big deal to me.

As for attributes, well I work in a 5.005 environment that we have not upgraded yet (when we do, I will have a couple of parsing bugs to look for), so that is not available to play with. However I would think that you could get attributes to work on package variables something like this:

{ my $tmp :some_attribute = "bar"; *foo = \$tmp; }
And if you can do it, then you can find some way to put synthetic sugar around it.

If you can't, then I would wonder why not. It would feel to me like a design kludge, unless I had a pretty good explanation why that naive expectation didn't make any sense. Even so, if I can't find a fairly nice way to explain to co-workers what the feature is, how to use it, and what the caveats are, then I won't use it. Perl has some obscure misfeatures that we already ignore (like prototypes). Adding a few more to that list is no problem...