Re (tilly) 1: autotie in Attribute Handlers

I looked at the code, and it looks to me to be a bug, but I don't know for sure what TheDamian intended.

Here is what is happening. Your argument list is always being turned into a reference to an array. If you process it that way in your tie implementation, it works just fine. If you don't, then you get your result.

Now if you look in the implementation, in import the variable $tiedata is defined in the following snippet:

        if ($cmd =~ /^autotie((?:ref)?)$/) {
            my $tiedata = '($was_arrayref ? $data : @$data)';
               $tiedata = ($1 ? '$ref, ' : '') . $tiedata;
            my $mapping = shift;
[download]

Now that looks to me to be an error, if you had an array reference, then leave it alone, if you didn't then try to dereference it as an array reference? If you didn't have an array reference, what possible sense does it make to dereference it as one?

Well if you try switching which branch of the trinary operator the array dereference takes place in, that code reads much more sensibly, and your test works entirely as you expected it to. However if you do that, 2 tests in the test suite fail. So I suspect that this is a bug in the code which was enshrined in the tests.

But I can't be sure of that without asking TheDamian. (I sent him a message.)

Comment on Re (tilly) 1: autotie in Attribute Handlers Download Code

Replies are listed 'Best First'.
Re: Re (tilly) 1: autotie in Attribute Handlers by TheDamian (Vicar) on Nov 04, 2001 at 03:27 UTC
Now that looks to me to be an error, if you had an array reference, then leave it alone, if you didn't then try to dereference it as an array reference? If you didn't have an array reference, what possible sense does it make to dereference it as one? No, the code you're querying is correct. You're missing the fact that the autogenerated handler also has this line in it: `\$data = [ \$data ] unless \$was_arrayref;` [download] So the effect of that code is to pass array refs to `tie` as array refs, and non-array-refs to `tie` as lists. There is a bug here, but it was elsewhere: namely that the codewasn't correctly distinguishing between an attribute with a list of args (`:Attr('list','of','args')`) and an attribute with a single array ref as an arg (`:Attr(['list','of','args'])`). I've now fixed that. There's a beta at http://www.csse.monash.edu.au/~damian//CPAN/Attribute-Handlers.tar.gz. Perhaps you and/or Marcel would like to see if it behaves more intuitively for you.	[reply] [d/l] [select]
Re (tilly) 3: autotie in Attribute Handlers by tilly (Archbishop) on Nov 04, 2001 at 04:27 UTC
That beta does fix that issue, but I consider its behaviour with the following line to be wrong: `my %hash : Test('one', 'two', 'three)');` [download] Any human looking at this would say that the first closing paren is inside of a quoted string, and so this code is correct. But Attribute::Handlers disagrees. It is perfectly willing to stop at the first paren, and claim that the passed argument was the string: `"'one', 'two', 'three"` [download] And therefore the following quote is interpreted differently than it should be. I assume that this is due to the heuristics it uses to parse Perl. If it is hard to fix (as I assume) then it is probably something to solve in 6.0. But I think it is a gotcha worth noting, along with the workaround: `my %hash : Test('one', 'two', 'three\)');` [download]	[reply] [d/l] [select]
Re: Re (tilly) 3: autotie in Attribute Handlers by TheDamian (Vicar) on Nov 04, 2001 at 05:12 UTC
Any human looking at this would say that the first closing paren is inside of a quoted string, and so this code is correct. Not a bug in Attribute::Handlers, but an inherent behaviour of the Perl 5 attribute mechanism. From attributes.pm: Each attribute specification is a simple name, optionally followed by a parenthesised parameter list. If such a parameter list is present, it is scanned past as for the rules for the `q()' operator. (See the section on "Quote and Quote-like Operators" in the perlop manpage.) The parameter list is passed as it was found, however, and not as per `q()'.	[reply]