princepawn, read the responses to your post and they'll answer your question. You can do the same thing with a hash and data dumper will return {}, which really explains what you generally need to know for that hash.
Second, I am really struggling to figure out what is going on here. This is at least the fourth post where you have basically said "Perl or some module doesn't do what it's supposed to do." In all of these cases, you were wrong. Rather than accusing Perl (or modules) of not performing to spec, you should ask why things are not performing the way you expect them to perform. Here are some examples where you made a claim that was wrong:
You've been bitten so many times by this, I have to wonder why you keep coming back for more. I'm sure you have more than these examples because I just grabbed a few of your more recent posts without bothering to search through all of your nodes.
Now to be fair, I have enjoyed some of your posts and I credit you with sparking my interest in Quantum::Superpositions. It's a fascinating module and I'm glad you raised my general awareness of it. But please, don't jump the gun and start saying "things don't work." Ask questions first! (I'll also give you credit for the bug in the Quantum::Superpositions documentation, but it's still nice to ask than accuse).
I can't tell you how many times I simply assumed that Perl was doing something wrong, and in all of my time programming in it, I have only found one legitimate bug. However, you'll note that I didn't just come out of my corner swinging, I asked what was going on.
Cheers,
Ovid
Join the Perlmonks Setiathome Group or just go the the link and check out our stats. | [reply] |
If I could upvote this a few more times, I would.
If Perl is consistently working in a way in which you don't expect it, perhaps
it's not Perl that is off. {grin}
There's this frequent contributor to P5P and the Usenet newsgroups who kept saying
things like "counter intuitive" for many of the features which distinguish Perl
from other languages. Eventually, reading those posts became tiresome, because
it became obvious that this person would just never be satisfied until Perl was
completely in sync with their internal model of "the world". That's sad. Sometimes,
it's about looking around and poking at things until you get your model in sync
with the world instead.
-- Randal L. Schwartz, Perl hacker
| [reply] |
You wouldn't be implying that at times it is a bad user on device error? :)
I have to admit there have been a few times that something wacky was happening with perl and I *really* wanted to blame it on somebody else because it was just so much easier than finding the error in my code.
| [reply] |
Do not use defined on hashes or arrays. It does not mean what you apparently think it means. It means something entirely useless to most Perl programmers: "does this aggregate variable have allocated memory for its contents". So, if it's defined, it has non-empty content, but the converse is not true.
-- Randal L. Schwartz, Perl hacker | [reply] |
Using defined() on aggregate types is a big
mistake. So stop that. The important thing is that @x
is empty. Whether @x is defined doesn't mean anything
interesting at all (I don't even remember what it means
because it isn't something I want to use).
The difference cropped up for me when getting back data
from grep, which returns undef when nothing in the input
list matches the criteria of the code block.
No, grep in a scalar context returns
a "false" value which might be undef (though
I doubt it). In a list context,
grep returns an empty list. If you do
@x= grep ..., then whether or not @x is defined
when you are done is not something you should ever
check or care about.
-
tye
(but my friends call me "Tye")
| [reply]
[d/l]
[select] |