What does a "list slice" return in a scalar context? It isn't actually documented (though some make outrageous claims that it is).
It's not outrageous. Stop being so disingenuous. perldata clearly says:
@days{'a','c'} # same as ($days{'a'},$days{'c'})
If you want a language defined by a formal specification, rather than by example,
you know where to find Java or Ada or PL/1.
And as always, patches welcome. Turn them in, or shut up about this.
-- Randal L. Schwartz, Perl hacker | [reply] [d/l] |
I don't really care that the behavior of a list slice in a scalar context isn't documented. What I mind is the silly claim that the comment "same as" in a one-line example about a hash slice (or even an array slice) is supposed to be considered as documentation about how a list slice behaves in a scalar context.
By your logic, the line just below that:
%days # (key1, val1, key2, val2 ...)
indicates that %days in a scalar context should return the "last" value of the hash. Or is it only when the magic "same as" words are written that it should become obvious to me that "same to the point of returning the same value in a scalar context" is meant, but not, for example, "same to the point of meaning the same thing when passed to localtime()" or any other possible overextensions of the term "same as"?
So unless you are accepting patches for your logic, I have none to submit. q-:
-
tye
(but my friends call me "Tye")
| [reply] [d/l] [select] |
Is this a case of, any logic that tye doesn't like
can be pinned on the other guy without clarification?
In (tye)Re3: Hash slices ? you point to this as a better explanation.
But when I read it I find no explanation at all.
In perldata I find 4 examples together. 2 of them say
that one thing is the same as the thing in the
comment. The two comments before and after carry no such
language, and in fact elsewhere have documentation that
makes it clear to users that they are not the
same as the thing in the comment in all situations.
However the comments describe a way of thinking about the
construct that is enlightening.
Now I don't know what reasoning you are projecting on
merlyn where the 2 statements without that
comment deserve the same treatment as the ones with.
I do know that if you take the statement the same
as at face value, that the behaviour in scalar
context is correctly predictable from statements elsewhere.
(Geez, almost as it it was supposed to be the same as?)
I succeeded in so predicting it from the documentation. I
have pointed at a specific post of mine as evidence of
that.
How you get from that to the assertion that merlyn (and
presumably myself) should make the same prediction from
comments where the comment at issue does not appear I
completely fail to understand. I mean, if those 3 words
were accurate in the remaining two cases, then I would
expect them to be there. Wouldn't that be reasonable?
After all 3 words are not hard to type. But instead they
are not there, and a couple of pages later there is
explicit documentation on what @days and %days are in
scalar context. You have to go a few more pages to get
to the section on list value constructors that documents
what explicit lists (you know the things that slices are
supposed to be the same as) are. And that documentation
is (oddly enough) correct!
In summary, the more you say on this, the more bizarre I
find it. What slices are supposed to be the same as, they
really do behave the same as. The documentation of that
is explained later. The comments that were not labelled
with that rather explicit phrase have their behaviour in
scalar context explained later, in detail. And all of
this documentation is correct.
| [reply] |