Re: Why would you use our?

Am I missing something?

Avoiding use vars and being able to give package variables associated types (our Dog $spot) wasn't enough to convince you?

Well, perhaps my new Attributes::Filtered module will be. Once it's available, by using our you'll be able to declare package variables (or parts of package variables, such as individual hash entries) with attributes.

Comment on Re: Why would you use our?

Replies are listed 'Best First'.
Re (tilly) 2: Why would you use our? by tilly (Archbishop) on Oct 19, 2001 at 16:03 UTC
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; }` [download] 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...	[reply] [d/l]

Replies are listed 'Best First'.

Re (tilly) 2: Why would you use our?
by tilly (Archbishop) on Oct 19, 2001 at 16:03 UTC

vars

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;
}
[download]

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...

[reply]
[d/l]