|
Re^4: referencing slices - love that DWIM
by syphilis (Archbishop) on May 17, 2008 at 13:35 UTC
|
I think there is no such thing as a reference to a list
1) BrowserUK quoted the documentation that
\(@foo) returns a list of references. Assuming that \(@foo) does, in fact, return a list (as stated by that documentation), then wouldn't [\(@foo)] have to return a reference to that list ?
2) I find it amazing that the current implementation of \(@foo) DWIMs for so many people. To me, it is blatantly obvious that DWIMness dictates that \(@foo) ought to return the same as [@foo]. (I know one other who shares the same view - but I have no doubt that we are in a minority.)
3) I should acknowledge that I don't really understand "lists" - and, having read numerous explanations, have grown to accept the fact that I probably never will.
Cheers,
Rob | [reply]
[d/l]
[select] |
|
|
| [reply] |
|
|
A list is an ephermeral thing; a transient set of values on the call stack
Ok ... so if, as the docs say, \(@foo) returns a list, then precisely what does [\(@foo)] return ? Is it (something like) "a reference to an array comprising the list returned by \(@foo)" ? (What's the correct terminology ?)
Cheers,
Rob
| [reply]
[d/l]
[select] |
|
|
|
|
However, from the point of view of a perl programmer they are as near as damnit the same thing.
| [reply] |
|
|
|
|
| [reply]
[d/l] |
|
|
Not sure what it would have to... :)
Yeah ... sometimes I get a bit literal about these things. My reasoning (undoubtedly flawed) is along the lines that the square brackets ([]) return a reference to whatever is within those brackets ... and if it's a list that's within those brackets (as stated by the docs), then those square brackets must be returning a reference to that list.
it returns a reference to an anonymous array which has been initialised with references to the list's individual elements/values
Something about that doesn't feel right to me. Do you mean "it returns a reference to an anonymous array which has been initialised with the list's individual elements/values" - and that, in this case, those "elements/values" are actually references ?
It's probably a bit confusing to be asking these sorts of questions in terms of the return of \(@foo). Surely there are simpler constructs that also return a list. Does, eg (1..10) return a list ?
Cheers,
Rob
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
To me, it is blatantly obvious that DWIMness dictates that \(@foo) ought to return the same as [@foo]
I've never liked \(@foo) and thought it should be no different from \@foo
(a reference to the array @foo).
My reasoning (undoubtedly flawed) is along the lines that the square brackets ([]) return a reference to whatever is within those brackets ...
Flawed, yes. [] creates a new array, initialized from the list given, and returns
a reference to it. This differs from "return[ing] a reference to whatever is within"
in that it is a shallow copy, so \@foo is affected by later changes to @foo's elements, while
[@foo] is not (unless those elements are references to other things which are changed.)
| [reply] |
|
|
I've never liked \(@foo)
Oh ... that now makes *3* of us that I know of.
I first came across this construct while building PGPLOT-2.18 on perl 5.8. One (or more) of the test files contained a line of code like (from test10.p):
pgline(128, \(0..127), $$img2D[127]);
The author (and I) were amazed to discover that what was intended to be the 2nd arg, was in fact 128 separate arguments. We were both convinced that this was a perl bug .... but were assured in no uncertain terms that it wasn't :-)
Update: As ysth says, it's not a bug and never was. (It has always been documented in perl 5.8.) But these were the early days of 5.8, neither Karl nor myself had studied the changes from 5.6. Why would we ? The behaviour was simply so counter-intuitive to us that it just *had* to be a bug :-)
Cheers,
Rob | [reply]
[d/l] |
|
|