Re^2: HTML::Element accessing "internal attributes" the proper way

> his will set $date to undef and might produce a warning.

this would surprise me

  DB<71> use warnings; $a=(1..2)[9]

  DB<72>
[download]

> so you might want to use eval: my $date = eval { $d->content->[1] }

Thats why the use is of ->content is discouraged and ->content_array_ref is offered

$content_array_ref = $h->content_array_ref(); # never undef
[download]

"This is like content (with all its caveats and deprecations) except that it is guaranteed to return an array reference."

> (All code obviously untested.)

dito! :)

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery}

Comment on Re^2: HTML::Element accessing "internal attributes" the proper way Select or Download Code

Replies are listed 'Best First'.
Re^3: HTML::Element accessing "internal attributes" the proper way by jcb (Parson) on Dec 26, 2020 at 01:30 UTC
I said "might" because I was not sure off the top of my head whether reading off the end of a list produces a warning in Perl or not. As the documentation says, `content_array_ref` is just as deprecated as `content`, with `content_list` being the preferred interface for new code.	[reply] [d/l] [select]
Re^4: HTML::Element accessing "internal attributes" the proper way (updated) by LanX (Saint) on Dec 26, 2020 at 02:54 UTC
> As the documentation says, `content_array_ref` is just as deprecated as `content` Not really, I can't see this in the documentation. And the author seems to be a bit confused about the inner mechanics of Perl. update After further reading. .. the issue seems to be that the ref returned is the one of an internal attribute `_content` , which "still" allows direct write access to children elements, but that's strongly discouraged. But as long as you are only reading and not writing, I can't see a reason to deprecated the whole method. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply] [d/l] [select]