Re: forks.pm finally supports : shared attribute, correctly?

[scrottie]

Hi, interesting module! I'll certainly have to check that out. Have you looked at Coro? I'm groovin' on that big time =)

If you were working in your own package and not inheriting anything, there would never be anything there. Since you're doing this in main or someone elses package, they might, or they might be inheriting something else that does. That wouldn't show up as a symbol table entry - you'd have to do:

  $self->SUPER::HANDLE_foo_ATTRIBUTES()

- in addition to what you're doing - just to be safe. But this assumes that other people are playing by the rules, too. Exporting is messy business. I'm not an attributes.pm expert.

In typesafety.pm's import(), I'm doing:

  push @{$caller.'::ISA'}, 'typesafety';

When people "use typesafety", their module is coerced into inherting from it as well, making my MODIFY_foo_ATTRIBUTES visible from their package without exporting it at all. However, something like you're doing would mask it and things would break. Other people with other modules that add attributes to other peoples code might be doing what you're looking for - exporting MODIFY_foo_ATTRIBUTES directly into the using module.

Off on a tangent (as usual), reading Arthur Bergman's code in types.pm, I discovered a very nifty trick (actually a few!)

Crawling the byte code tree using B/B::Generate,

    my $name = (($curcv->PADLIST->ARRAY)[0]->ARRAY)[$targ];  
    return unless $name->can('SvSTASH'); 
    my $type = $name->SvSTASH->NAME;

For any given targ ($opcode->targ(), the "target", or index of a lexical variable in the current padlist - in other words, a "my" variable), you can see which package it was declared as being in using the new "my" syntax:

  my FooBar $bar;

Given the targ index of "$bar" in the current pad, we can find out that "$bar" is supposed to be a FooBar!

Because of this, I'm able to drop use of attributes from typesafety (and Mr. Bergman was able to avoid them entirely in the first place).

Of course, you probably aren't crawling the bytecode tree with B::Generate, but I thought this was an intersting footnote =)

-scott