Deep structure access and temp variable

[Charles DeRykus]

... all perceived shortcomings in his text are really intentional
omissions, at least in hindsight, lest he would have to admit that he
made some mistakes.

In case this seems overly cryptic: Perl doesn't have 'data structures'
it has various kinds of objects and references to objects. This means
unless the author provides a definition of 'data structures' in the
context of Perl, a reader has to guess what was meant by that and
guessing that it was supposed to mean 'objects' isn't very far
fetched.

Leaving this aside, this 'cheat sheet' is a partially erroneous
paraphrase of the 'Using references' section of the perlref manpage:

1. Anywhere you'd put an identifier (or chain of identifiers)
as part of a variable or subroutine name, you can replace
the identifier with a simple scalar variable containing a
reference of the correct type:

[...]


2. Anywhere you'd put an identifier (or chain of identifiers)
as part of a variable or subroutine name, you can replace
the identifier with a BLOCK returning a reference of the
correct type.

[...]

3. Subroutine calls and lookups of individual array elements
arise often enough that it gets cumbersome to use
method 2. As a form of syntactic sugar, the examples
for method 2 may be written:

$arrayref->[0] = "January"; # Array element

[...]

The arrow is optional between brackets subscripts

This is not only complete and correct but also (IMHO) no more
difficult to understand than the other text.

Tye's cheat sheet dates from 2001 and still provides a short, useful
guide. He carefully qualified its scope. You could comment/critique
Tye's page fully on that forum and/or publish your own as as updated,
improved version.

 

[Rainer Weikusat]

[Rainer wrote:]
[Charles (IIRC?) wrote:]

A nice reference cheat sheet by Tye McQueen:
http://www.perlmonks.org/?node=References quick reference

This is incomplete. It doesn't mention code references,

The author reminds a commenter that

... all perceived shortcomings in his text are really intentional
omissions, at least in hindsight, lest he would have to admit that he
made some mistakes.

In case this seems overly cryptic: Perl doesn't have 'data structures'
it has various kinds of objects and references to objects. This means
unless the author provides a definition of 'data structures' in the
context of Perl, a reader has to guess what was meant by that and
guessing that it was supposed to mean 'objects' isn't very far
fetched.

Do you ever get tired of being snide, pedantic and somewhat
unpleasant?

Perl has data structures. They are the things described in perldsc, the
Perl Data Structures Cookbook. Perl also has objects, which are
something rather different, and are not covered in Tye's tutorial.

"Tye's tutorial" is a bad rehash of a perl man page. Did it already
occur to you that you're implicitly trashing the guy who wrote the
more useful text?

 

[Rainer Weikusat]

[Rainer wrote:]
[Charles (IIRC?) wrote:]

A nice reference cheat sheet by Tye McQueen:
http://www.perlmonks.org/?node=References quick reference

This is incomplete. It doesn't mention code references,

The author reminds a commenter that

... all perceived shortcomings in his text are really intentional
omissions, at least in hindsight, lest he would have to admit that he
made some mistakes.

In case this seems overly cryptic: Perl doesn't have 'data structures'
it has various kinds of objects and references to objects. This means
unless the author provides a definition of 'data structures' in the
context of Perl, a reader has to guess what was meant by that and
guessing that it was supposed to mean 'objects' isn't very far
fetched.

Do you ever get tired of being snide, pedantic and somewhat
unpleasant?

To answer that question: One reason why I'm on USENET is because I'm
interested in discussing things. Unfortunately, many USENET
'discussions' don't really qualify for that but people who are more
into throwing bottles at others in order to express their discontent
with them (something which happened to me yesterday evening) at least
can't really do that.

 

[Jürgen Exner]

Of course Perl has data structures. Support for the abstract data
structures 'list' and 'mapping' are built into the very core of the
language.

Do you ever get tired of being snide, pedantic and somewhat unpleasant?

That's what filters are for.

jue

 

[Rainer Weikusat]

Quoth Rainer Weikusat <[email protected]>:
[...]

Perl doesn't have 'data structures' it has various kinds of objects
and references to objects.

[...]

Perl has data structures. They are the things described in perldsc, the
Perl Data Structures Cookbook. Perl also has objects, which are
something rather different, and are not covered in Tye's tutorial.

This will probably earn me the 'pedantic' accusation again but so be
it: I was using 'object' in the sense it is used in the C standard,
for want of a better term for that: It's meaning is roughly "some
typed thing which can be allocated, deallocated and deal with directly
by code written in $language". The term 'first class citizen' is also
used to refer to that. In Perl, a behavioural definition of 'object'
in this sense could be "something the \-operator can be applied to [if
it isn't anonymous]", ie, scalar, arrays, hashes, subroutines, globs
and a few more, less common somethings. Another definition could be
'something which is either a glob can be "stored" in a glob slot'.#

In hindsight, I understand that the author of this 'cheat sheet'
intended to partition the set of perl objects into 'proper' and
'fishy' ones, presumably based on experiences with
$other_programming_language, however, that wasn't obvious to me when
reading the text and I also disagree with this partitioning. I use
anonymous subroutines, mostly closures, very frequently, and I also
write code which generates code at runtime frequently. Perl support
for the latter is fairly poor because it requires generating source
code text and running that through the compiler via eval but
nevertheless existant and useful: subroutines are almost 'first class
citizens' in Perl.

I've been doing an unholy amount of Java programming recently and some
things which are very simple in Perl, eg, write a general
'structured thing' comparison routine, are hideously complicated in
Java because its support for treating 'functions' as 'objects' is even
poorer than that of C (I have such a routine with a limited scope and
the code necessary to invoke that is only about 50% less than the
comparison code itself): Perl is a nice language because of its more
uncommon (in 'mainstream programming languages') features, not a nice
language despite of them because it enables people to build
punctuation cascades capable of reducing grown men to tears and
routinely outclevering everyone (including themselves) in the
process.

 

[Willem]

Ivan Shmakov wrote:
)
) [...]
)
) > # Version 2
)
) > my $tmp = $stuff->{a}{b}{c}{d};
) > my $A = $tmp->{e};
) > my $B = $tmp->{f};
) > my $C = $tmp->{g};
)
) > What is the most efficient? What appears to be the most idiomatic?
)
) FWIW (and now that the experts have said their word), my
) personal preference would be to write it as follows:
)
) my $tmp = $stuff->{a}{b}{c}{d};
) my ($A, $B, $C) = @$tmp{qw (e f g)};

Writing it that way obviates the need for a temporary variable,
so why don't you write this:

my ($A, $B, $C) = @{$stuff->{a}{b}{c}{d}}{qw(e f g)};


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT