in reply to undef as an lvalue
You may assign to undef in a list. This is useful for throwing away some of the return values of a function: ($dev, $ino, undef, undef, $uid, $gid) = stat($file);
-- Randal L. Schwartz, Perl hacker
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: Re: undef as an lvalue
by dvergin (Monsignor) on Feb 25, 2001 at 11:03 UTC | |
All of which is related to but a bit different from the following which (like the first example above) does not return values-in-a-list but still manages to force a list context for what will be returned by the regex (or any other expression that can return scalar or list). That elusive ghost list can then be construed into a scalar count of the list elements: Even more ephemeral. But the "$count = () = m//" construct can be handy occasionally. Update: a friend asked for an example of 'handy'. Herewith offered:
| [reply] [d/l] [select] |
by chromatic (Archbishop) on Feb 26, 2001 at 02:35 UTC | |
Without looking at the code, I'm 95% sure it's the latter. Why write a special case for what's already a special case? To illustrate what I mean, consider using an assignment as a conditional: Scoped as you expect, and behaves as you expect. Using undef as an lvalue within a list is the special case. The fact that that assignment evaluates to what you'd expect with a regular assignment is not. | [reply] [d/l] |
by tye (Sage) on Feb 26, 2001 at 09:31 UTC | |
Since this sets @y to (3) not (3,4) nor (2), I think these are actually modifiably undefs. But that makes perfect sense to me considering subroutine arguments...
When you pass things to a subroutine, @_ usually ends up holding aliases to variables passed in. That is, you can modify the variables by modifying $_[2], for example. But if you pass in an expression, then the subroutine gets a copy instead of an alias. In the case of undef, Perl has several choices: 1) It could pass in an alias to the one, read-only undefined value. 2) It could pass in a modifiable copy of the undefined value. 3) It could pass in a read-only copy of the undefined value. In our last line of code above, Perl is passing in a alias to the read-only value "goodbye". This makes some sense in that it catches certain coding mistakes. But, since this is Perl, that is probably mostly considered unfortunate, the preference being to be flexible and allow such strange practices for which it is hard to imagine a use (until, of course, you have a use for them). So I think the real reason it does this is to avoid the overhead of copying the possibly large value. In the case of undef, I think Perl always passes in a writeable copy because: 1) undef is never large and 2) it can be handy to pass in undef even though the subroutine intends to modify that argument. So undef can be used to mean "I don't care" about that value and the subroutine doesn't have to be coded to check for that case. Very Perlish. So when building a list, undef is always copied and so become modifiable. - tye (but my friends call me "Tye") | [reply] [d/l] [select] |
by MeowChow (Vicar) on Feb 26, 2001 at 00:41 UTC | |
MeowChow s aamecha.s a..a\u$&owag.print | [reply] [d/l] |