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:
And if you can do it, then you can find some way to put synthetic sugar around it.{ my $tmp :some_attribute = "bar"; *foo = \$tmp; }
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...
In reply to Re (tilly) 2: Why would you use our?
by tilly
in thread is use strict a compile time directive?
by princepawn
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |