Skip Menu |
 

This queue is for tickets about the XML-Twig CPAN distribution.

Report information
The Basics
Id: 62204
Status: resolved
Priority: 0/
Queue: XML-Twig

People
Owner: Nobody in particular
Requestors: jmgdoc [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 3.36
Fixed in: 3.38



Subject: XML::Twig::Elt att() accessor behavior change (lvalue issue)
Download (untitled) / with headers
text/plain 652b
Since the XML::Twig::Elt att() accessor is :lvalue, its behavior as a read accessor is changed. Assuming that foo() is an arbitrary user-defined function, the first instruction below should produce the same result as the 2-line following sequence: $result = foo($elt->att('any_attribute')); $value = $elf->att('any_attribute'); $result = foo($value); It was true up to XML::Twig 3.35, but it no longer works in 3.36 and 3.37. Due to some lvalue-related side effect, the first form (i.e. when the att() call is directly used as an argument for another function call), it *creates* the attribute (with an empty string as value) if it was not defined.
The issue comes with various Perl versions including 5.10.1, 5.12.0, 5.12.1, 5.12.2RC1
Subject: Re: [rt.cpan.org #62204] XML::Twig::Elt att() accessor behavior change (lvalue issue)
Date: Sun, 17 Oct 2010 20:37:31 +0200
To: bug-XML-Twig [...] rt.cpan.org
From: Michel Rodriguez <xmltwig [...] gmail.com>
Download (untitled) / with headers
text/plain 1.2k
On Sun, Oct 17, 2010 at 4:09 PM, Jean-Marie Gouarné via RT <bug-XML-Twig@rt.cpan.org> wrote: Show quoted text
> Sun Oct 17 10:09:47 2010: Request 62204 was acted upon. > Transaction: Ticket created by JMGDOC >       Queue: XML-Twig >     Subject: XML::Twig::Elt att() accessor behavior change (lvalue issue) >   Broken in: 3.36 >    Severity: Important >       Owner: Nobody >  Requestors: jmgdoc@cpan.org >      Status: new >  Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=62204 > > > > Since the XML::Twig::Elt att() accessor is :lvalue, its behavior as a > read accessor is changed. Assuming that foo() is an arbitrary > user-defined function, the first instruction below should produce the > same result as the 2-line following sequence: > > $result = foo($elt->att('any_attribute')); > > $value = $elf->att('any_attribute'); > $result = foo($value); > > It was true up to XML::Twig 3.35, but it no longer works in 3.36 and > 3.37. Due to some lvalue-related side effect, the first form (i.e. when > the att() call is directly used as an argument for another function > call), it *creates* the attribute (with an empty string as value) if it > was not defined.
Oops! I'll look at this tomorrow Thanks -- mirod
Download (untitled) / with headers
text/plain 1.1k
On Sun Oct 17 14:37:41 2010, xmltwig@gmail.com wrote: Show quoted text
> On Sun, Oct 17, 2010 at 4:09 PM, Jean-Marie Gouarné via RT > <bug-XML-Twig@rt.cpan.org> wrote:
Show quoted text
> > Since the XML::Twig::Elt att() accessor is :lvalue, its behavior as a > > read accessor is changed. Assuming that foo() is an arbitrary > > user-defined function, the first instruction below should produce the > > same result as the 2-line following sequence: > > > > $result = foo($elt->att('any_attribute')); > > > > $value = $elf->att('any_attribute'); > > $result = foo($value); > > > > It was true up to XML::Twig 3.35, but it no longer works in 3.36 and > > 3.37. Due to some lvalue-related side effect, the first form (i.e. when > > the att() call is directly used as an argument for another function > > call), it *creates* the attribute (with an empty string as value) if it > > was not defined.
OK, there are ways to fix this, but the only clean one I found was to use Want, which is a dependency I don't want to have, as it is an XS module. Plus it implies quite a bit of processing for something as simple as getting an attribute value So I ditched att and class as lvalues latt and lclass are now lvalues. __ mirod


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.