not to pick nits, but i've never seen either message. i was simply asking about something i had read in the Camel book and wondering how it applied to my code. i've been doing due diligence in RTFM, but it's hard to read something you've never seen.
i've included here the definition of deprecate as defined by Merriam Webster online. i can see using definitions 2 or 3 when discussing features that will not be included in future releases, but it's quite a stretch for me to see this word used in context with something that will be _included_ in a future release. (2 comes close, but i still think a better message could be given.)
Main Entry: dep·re·cate
Pronunciation: 'de-pri-"kAt
Function: transitive verb
Inflected Form(s): -cat·ed; -cat·ing
Etymology: Latin deprecatus, past participle of deprecari to avert by prayer, from de- + precari to pray
Date: 1628
- a archaic : to pray against (as an evil) b : to seek to avert [deprecate the wrath ... of the Roman people -- Tobias Smollett]
- : to express disapproval of
- a : PLAY DOWN : make little of [speaks five languages ... but deprecates this facility -- Time] b : BELITTLE, DISPARAGE [the most reluctantly admired and least easily deprecated of ... novelists -- New Yorker]
- dep·re·cat·ing·ly /-"kA-ti[ng]-lE/ adverb
- dep·re·ca·tion /"de-pri-'kA-sh&n/ noun
i apologize for the attitude of this post, but it's been one of those days, and the implication that i don't know how to find out things on my own really irks me. | [reply] |
| [reply] |
tye is clearly correct about what is deprecated, but I
personally see the language as being both precise and
correct. The word "our" was reserved by Perl (though at
that point not yet used) and using that reserved word as
a bareword is deprecated. Which is exactly what it
said.
I am sorry that the implication you didn't know how to
find information irked you though. Perl has excellent
and comprehensive documentation which a tremendous amount
of work has been put into. Regrettably most people who
are introduced to the language are not shown the
documentation and have no idea how to use it. If you were
in the (good) habit of looking to that documentation then
the first thing you would have done is typed, "perldoc
perl". Scan down that index and you would have found the
following section:
perldebug Perl debugging
perldiag Perl diagnostic messages
perlsec Perl security
perltrap Perl traps for the unwary
perlport Perl portability guide
perlstyle Perl style guide
All of these are good reads, except perldiag which is
meant to be a reference. Now you type "perldoc
perldiag", and search for your message. (Type in "/",
a chunk of text, then return. Hit "n" as often as needed
until you reach the right section.) Try that, time how
long it takes. I bet it is under 5 minutes.
Now it is likely that you cracked open the Camel book for
this, possibly loooked in chapter 9. And you did not find
the documentation. Well the reason for that is that the
documentation that you are reading is for Perl 5.003, and
the message you are reading is from Perl 5.005. After two
minor revisions of the language there are different
diagnostic messages. While the Camel book is both valuable
and good, the current online documentation (ignored by
most Perl programmers) is always going to be more
accurate.
So whether or not you are irked, it is true. You made a
perfectly understandable mistake out of very understandable
ignorance of how to use the documentation system that Perl
comes with. If I got irked every time I made such a
mistake I would have little time for anything else! Just
today I found that I was leaving zombies because I was not
calling wait properly. Darn. Didn't know I had to do
that. Ask KM if you don't believe me, I used him as the
classic "blank wall" while I realized my error. (My
background really is math, not Unix programming.) Clearly
that is "Mea culpa!" My bad! OK, fix my code, file that
away, and move on. I won't do that again.
So again. You didn't know how to RTFM. Now you do. There
is no fault in not knowing, or even in having used Perl for
years and not knowing. The fact is that most Perl
programmers do not know. (The only person
in that thread who gave the right answer is someone whose name I immediately
recognized as a Perl guru. That says a lot. Much of it
not very good.) That is a different problem.
A serious one IMO, but not yours. A lot of work has gone
into producing documentation that very few people read,
and something needs to be done about that. (Do you have
any suggestions?)
The only way that I could possibly think less of you for
your not knowing what you were never told would be if you
did not take this
as a sign that you should develop the skill and habit
of reaching for perldoc every time you are not positive of
some detail. Develop that skill and your next unknown
Perl diagnostic will take under 3 minutes to answer, in
detail, with an answer that I guarantee is accurate.
Regards,
Ben Tilly
PS As for, "It's been one of those days" - well I think we
have all been there. Many, many times. At least I have...
PPS BTW another gem, Perl has a naming convention. It will
never reserve for its use any bare-word that is not
"seriously weird" (like $@), all upper case, or all lower
case. And yes, there is a convention on what types of
variables fit which description as well. Therefore if
you either never use barewords, or else you always have
mixed case, you will never, ever, conflict with any keyword
in the language. | [reply]
[d/l] |
I personally see the language as being both precise and correct. The word "our" was reserved by Perl (though at that point not yet used) and using that reserved word as a bareword is deprecated. Which is exactly what it said.
I respectfully (though strongly) disagree. And I do respect your contribution above and many others of yours. So please try to not let the strength of my disagreement come across as a criticism of you.
The use of "our" is not depricated (as the message claimed). The use of "our" as a bareword is depricated. Other uses of "our" are being encouraged, though just not yet. Consider the two error messages:
Use of %s is deprecated
Use of reserved word """"%s"""" is deprecated
They mean nearly the opposite (a feature is being added vs. a feature is going away), but sound nearly identical (in fact, you could correctly substitute the second for the first in most cases since the deprecated feature is usually still a reserved word!). The important parts of the latter (that it is being reserved for future use and that your use of it is being parsed as a bareword) are omitted. The term "reserved word" strongly implies that Perl considers "our" to be a keyword, while the important fact is that it isn't yet.
That error message is (only slightly) incorrect. But the error message is very, very misleading. Also, the message is so simple and easy to understand (though incorrectly) that I can't fault someone (much) for not thinking to go read perldiag.pod to see if, perhaps, the message actually means nearly the opposite of what it says.
Finally, the original use of "our" as a bareword was not based on a lack of knowledge of the fact that using all-lowercase barewords is a bad idea. It was based on the knowledge that "our" is a keyword in Perl, and a lack of knowledge of the fact that the version of Perl being used wasn't the a version that supported "our".
-
tye
(but my friends call me "Tye") | [reply]
[d/l] |