chromatic wrote:
On Wednesday 05 April 2006 14:09, Adam Kennedy wrote:
And now in return, we have new modules that changes the way EVERYBODY
else's code works, and changes the meaning of that code instead, so
Test::MockObject gets less spurious bug reports.
You mischaracterize the situation.
There is no possible way that Test::MockObject or Test::MockObject::Extends
could work if someone were to call UNIVERSAL::can() or UNIVERSAL::isa() as a
function on an instance of either class.
By using both modules, I can detect nearly all incorrect uses, work around
them, and warn that the broken code will probably not work correctly and
needs exploration.
How is that not valuable for users of my code?
(I do grant that getting this code right is difficult and my core perl bug
remains unfixed, but I have an idea.)
And to make matters worse, now there's a warning suppression option, so
they now just magically change the way the code works, potentially
breaking it without warning.
The code was already broken. It was *impossible* for Test::MockObject or
Test::MockObject::Extends to work in certain cases. Using UNIVERSAL::isa and
UNIVERSAL::can makes it possible to detect those situations and work around
them, if possible, but at least warn about them.
For people who don't care about the warnings, they have the option of
disabling them.
I welcome legitimate bug reports and test cases to both modules and try to fix
them when possible.
I don't really see the point of warning about a usage but not correcting it.
(Isn't it Python's shell that, when you type Ctrl-d, says "Type 'exit' to
exit."? What's the point in that? I want to exit, you know I want to exit,
and I don't care if you warn -- but don't make me read your mind.
Interactive shells should not be parser-hampered text adventures.)
For example, Template::Toolkit may *never* work with Test::MockObject
because the author refuses to ask the author of CGI.pm to fix a bug in
the latter module, despite apparently knowing about it for several years
and apparently preferring to break my code instead.
Turnabout is not fair play when it comes to bugs.
I fail to understand. Should I not fix bugs because someone might rely on the
broken behavior?
The problem is that it isn't the behavior that is wrong, only their use
of it.
UNIVERSAL::isa/can when called as a function does a very specific thing,
and one that is often misunderstood.
And if you were able to distinguish between good and bad uses, then fine.
The problem comes that under UNIVERSAL::isa/can there is NO way to
UNIVERSAL::isa/can in the documented way.
If a warning was generated, then at least those people using it for the
correct reason would be able to disable warnings. But that doesn't
happen. And it's going to cause problems down the road, as all this sort
of magic does. It's going to end up interacting in unexpected ways with
someone else's magic and explode.
I keep adding bugs for new more-evil cases as I encounter them, and to
you credit you keep fixing them (that re-entrant bug might be tricky
though) but I can see some time soon we're going to reach a point where
we are going to have bugs that can't be fixed.
If there was a way to have the code that knows what it's doing still be
able to do what they mean work, I wouldn't care so much.
But when you fix the broken cases, you also break the working cases.
That these ways are subtle just means that we aren't going to see them
for a while.
Adam K
Template::Toolkit has a bug. Chris Dolan reported it. I confirmed that it's
TT's problem. Andy won't fix it. I will do all I can to work around it in
Test::MockObject, but I can't fix it without forking Template::Toolkit. The
best I can do is put up in big flashing neon letters, "Hey, there's a bug in
this other code and my code will never work correctly here. Beware."
Again, being explicit when possible when things won't work seems like a big
benefit to users. (Besides, I assume heavily that people won't use
Test::MockObject much outside of tests, where they ought to be able to debug,
well, bugs.)
-- c
