in reply to Behaviour of parsed XML

I hate the software that does not keep the return value consistent. Short of asking a parser for an array reference (somehow) regardless of number of items present, however, I do not see a parser to always return an array reference in the situation described. With that out of the way ...

Your problem seems to be of variable scope. Why do you have "my" in ... 

if (exists($data->{channel}->{title})) {
  ...
  my $data->{channel}->{item}->[0]=$mydata;
  ...
}

[download]

...? After the end of the if-block, $data->{channel}->{item}->[0] ceases to exist due to my operator.

Try ... 

use strict; use warnings; use Data::Dumper;

my $x;
{
   my $x->{a}->[0] = "no you don't!";
   #  my op also affects unrelated keys. Why?
      $x->{c}->[0] = "try this with previous 'my' for extra fun";
}
{
   $x->{b}->[0] = "now you see";
}
print Dumper $x;

__END__
$VAR1 = {
          'b' => [
                   'now you see'
                 ]
        };

[download]

In perl 5.30.1, I am disturbed by the fact that "extra fun" does not make into the Dumper output (but not disturbed enough to file a problem report myself).

After tobyink & haukex had set me straight, please ignore the above code; try this ... 

use strict; use warnings; use Data::Dumper;

my $x;
{
   my $x->{a}->[0] = "no you don't!";
}
{
   $x->{b}->[0] = "now you see";
}
print Dumper $x;

__END__
$VAR1 = {
          'b' => [
                   'now you see'
                 ]
        };

[download]

Replies are listed 'Best First'.
Re: Variable scope issue- effect of "my" on hash ref keys, values
by tobyink (Canon) on Feb 26, 2020 at 13:16 UTC

    Why would the "extra fun" bit be in the output? You declared two separate $x variables and they're each references to different hashes. If you put data into one hash, it shouldn't appear in the other one.

    The only arguable improvement which could be made to Perl with regard to this, is that my $x->{a}->[0] is kinda weird and might be worth warning about. Really that's just a precedence thing though. my is higher precedence than the deref operator, so it just means (my $x)->{a}->[0].

    toby döt ink
[reply]
[d/l]
[select]

      Ha! Right you are. I had missed the fact a spanking new variable was created inside the block (when assigning to the hash reference keys). No "extra fun" for me, it's obvious now.

      I was mistakenly thinking that my operator was affecting the existence of keys, values (in that {a} element was autovivified and only [0] element was localized to the block) but not the $x created earlier outside the block. Much thanks to you both for the clue bat.

[reply]
[d/l]
[select]
Re: Variable scope issue- effect of "my" on hash ref keys, values
by haukex (Archbishop) on Feb 26, 2020 at 13:16 UTC
    I am disturbed by the fact that "extra fun" does not make into the Dumper output

    I'm pretty sure that's because my $x->{a}->[0] = "no you don't!"; is mostly equivalent to my $x; $x->{a}->[0] = "no you don't!";. From Private Variables via my():

    All listed elements must be legal lvalues. ... The my is simply a modifier on something you might assign to.
[reply]
[d/l]
[select]
Re: Variable scope issue- effect of "my" on hash ref keys, values
by Veltro (Hermit) on Feb 26, 2020 at 13:23 UTC

    In perl 5.30.1, I am disturbed by the fact that "extra fun" does not make into the Dumper output (but not disturbed enough to file a problem report myself).

    Not 100% sure what you mean, but to me that makes sense. You still have my $x->... declared in the scope of the first block the next statement just adds to that locally scoped var inside that same block.

[reply]
[d/l]

In Section Seekers of Perl Wisdom