On 18/05/2011 21:37, Kenneth Wolcott wrote:
Ken, this is your OP. If my replies have been wrong then I will
certainly raise my hand to it, but:
A colleague claims that he made no changes, code worked yesterday and
doesn't today.
He is not using OO Perl.
I have asked him for a small code snippet that reproduces the error (I'm
sure he is unwilling to show the entire code!).
We have rules requiring the standard use of "use strict" and "use
warnings" in all our Perl scripts.
We use Perl on Windows, Linux and Solaris (all his scripts are supposed to
run without modification on Linux and Windows).
None of this is information. All it does is to imply that you have a
colleague whom you don't trust, and you have to solve a problem with
code that you don't expect to have access to.
He claims this: "use strict; use warnings; use XML::XPath;"
You don't trust your partner. We have no idea whether or not the
programs have strict or warnings in force, or whether XML::XPath is
available.
Trying to get value for:
$ha = $xPath->findnodes('//job');
Error:
Can't call method "findnodes" on unblessed reference at<file_name> line
<line_number>.
So presuming the code line
$ha = $xPath->findnodes('//job');
is causing the error you describe, then $xPath is not a blessed object
with a findnodes method. In fact it is not an object at all, as the
error message says it is unblessed.
But you say that He is not using OO Perl, so you cannot expect a blessed
reference from anything He writes.
If you are truly required to debug other people's code without site or
control of it, then you must write your own test environment. As long as
you can demonstrate that your code works with a real $xPath with a
findnodes method your code is demonstrably correct.
But writing correct Perl is not about what your colleague says or
claims. It is also not about fixing their code so that it works with yours.
Please establish that, if your colleague exists, he is is in fact
writing OO code that returns XML::XPath objects. Perl isn't great at
encapsulation, but it can be enforced procedurally. If it relies on
fist-waving over office compatrments it can never work.
I am still not sure that your colleague exists. If he does then you need
to drag yourselves in front of your manager and declare your
differences. If not, then you simply have doubts about your program
design, and you should meet with the best programmers that you trust to
resolve your doubts, as well as all the others that you will come across
as the project proceeds.
I usually sign 'HTH' and I always hope I have helped. A few people have
disagreed with me tonight; and while that leaves me wondering whether I
have been right, I also wonder why comments here are either negative or
non-existent.
I allow myself to be wrong, but I have no wish to draw others along a
wrong line. Ken, thank you for your post, but I believe you would help
us if you would talk about the result of your conversation with this
colleague that you seem to me to have no respect for.
Rob
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
