I mean specifically the Perl 5 feature. The docs say it is an error to use one that is not recognized. So how do strings you want to use as attributes become "recognized"? If you can just use anything (warning if all lower case), the doc is wrong.

John M. Dlugosz,
I will quote the section germane to the conversation:

An attempt to set an unrecognized attribute is a fatal error. (The error is trappable, but it still stops the compilation within that eval.) Setting an attribute with a name that's all lowercase letters that's not a built-in attribute (such as "foo") will result in a warning with -w ...

I agree that the docs could use some explanation (echo'd by others in the thread I pointed to). On that front I can't offer you any insight other than to say that if you ignore the attributes pragma and use one of the modules, it does just seem to work. The only module I found useful (run arbitrary code at different phases) though (Attribute::Handlers::Prospective) used source filters.

Cheers - L~R

I can't point you to any documents or sample code right now but, in Cat at least, they are arbitrary strings which are parsed out. "Unrecognized" ones would only be fatal in this context if you intentionally made misparsing of them fatal. I have mixed feelings about them because it is just string wrangling here. They are very useful but seem clumsy (you can stack up a bunch of them for one controller sub) and I think it might be nice if the new Moose stuff would mutate them into some other syntax eventually.

I think that MooseX::MethodAttributes might be what you are looking for. It is a nice meta-level API to sub attributes, and came out of the Catalyst Moosification I think.

-stvn

Thanks much. I only this weekend upgraded my main Cat stuff to 5.8 (on Moose). I was mildly amazed that nothing broke. I'm still a total Moose newbie but I really appreciate and admire the effort you and Dave and Sartak et al have put into it. I like seeing the frequent releases too.

I checked it out...

It's one page. Hack 45 (everything is called a "hack"), which shows that they exist and uses Attribute::Docstring and mentions Attribute::Handlers to make more things like that.

I'm not sure I understand the question. Maybe this code example is what you're looking for?

use strict;
use List::Extract 'extract';

sub MODIFY_CODE_ATTRIBUTES {
  my $class = shift;
  my ($cref, @attrs) = @_;

  my ($bent) = extract { /^Bent\b/ } @attrs;

  if (defined $bent) {
    print "Recognized attribute: $bent\n";
  }

  return @attrs; # Unrecognized.
}

sub foo :Bent;
sub bar :Bent(named) { 1 }

my $code = sub :Bent(anonymous) { 1 }

__END__
Recognized attribute: Bent
Recognized attribute: Bent(named)
Recognized attribute: Bent(anonymous)
[download]

What to do once a subroutine attribute is recognized is a completely different story. :-)

lodin

So only built-in attributes are recognized globally? That would contradict the examples. He's not setting up any package-attribute handler; just using Bent. And cautioning against unrecognized in nearly the same breath.

So only built-in attributes are recognized globally?

Correct. And that is how it should be. You don't want global attributes any more than you want global subroutines. I'm not saying that I like the current implementation, but at least its good that the attributes are somewhat scoped.

Since the handlers (MODIFY_CODE_ATTRIBUTES etc) are inherited one can add them to UNIVERSAL and achieve global attributes. Attribute::Handlers for instance uses this trick. This however makes it very dangerous to use attributes in modules, since attributes defined in different modules may clash. See also my previous meditation on the problems with attributes (it also links to other nodes about attributes).

lodin