I think Domizio's case is similar, even though it's not a sub-class, because it passes all the current CGI::App tests.
I would be careful about stating that it passes all the tests, because I don't believe it does. The failures seem to be minimal but they are there.
it's not a matter of belief... I have just taken all the current files in the C::A test suite, and I changed the base cllas with ::Plus, and used them as test suite for my own module. You can reproduce the same.
Here is what I got:
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/01cgiapp...........ok 17/19Params (5): P5, P3, P2, P4, P1
Values:
P5 => 'five'
P3 => 'new three'
P2 => 'two'
P4 => 'four'
P1 => 'one'
Params (7): P7, P5, P6, P3, P2, P4, P1
Values:
P7 => 'seven'
P5 => 'new five'
P6 => 'six'
P3 => 'new three'
P2 => 'two'
P4 => 'four'
P1 => 'one'
Params (8): P7, P5, P6, P3, P2, P8, P4, P1
Values:
P7 => 'seven'
P5 => 'new five'
P6 => 'six'
P3 => 'new three'
P2 => 'two'
P8 => 'eight'
P4 => 'four'
P1 => 'one'
t/01cgiapp...........FAILED test 18
Failed 1/19 tests, 94.74% okay
t/02mailform.........ok
t/03prerun...........NOK 9# Failed test (t/03prerun.t at line 61)
# 'Error executing run mode "nothing_special": No run-method found for run mode "nothing_special" at t/03prerun.t line 55
# at t/03prerun.t line 55
# '
# doesn't match '(?-xism:prerun_mode\(\) can only be called within cgiapp_prerun\(\))'
t/03prerun...........NOK 10# Failed test (t/03prerun.t at line 76)
# 'Too early to call this method at ../OOTools-1.6/blib/lib//Class/constr.pm line 36
# '
# doesn't match '(?-xism:prerun_mode\(\) can only be called within cgiapp_prerun\(\))'
# Looks like you failed 2 tests of 10.
t/03prerun...........dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 9-10
Failed 2/10 tests, 80.00% okay
t/04getquery.........ok
t/05arrayrefmodes....ok
t/06enhancement31....ok
t/07postrun..........ok
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/01cgiapp.t 19 1 5.26% 18
t/03prerun.t 2 512 10 2 20.00% 9-10
Failed 2/7 test scripts, 71.43% okay. 3/52 subtests failed, 94.23% okay.
make: *** [test_dynamic] Error 255
It looks worse than it actually is, but it still fails. The first failure is the param() change you mention below. And last 2 failures appear to be a change in error messages, although It looks to me like test 9 in t/03prerun fails with the wrong error message (that still may not cause any code incompatibilities but it would require a lot more investigating that I am willing to do)
The ONLY test it does not passes ON PURPOSE are the tests of the param method in scalar context ONLY, that I changed to correct what IMHO is an useless behaviour of C::A. The "correction" allows you to do several things with the param() method that the C::A::param() does not allow. It's documented in the section "Compatibility with C:A".
I missed that part of the documentation. It is a bit confusing because in one sentance you say "this module pass all the tests of CGI::Application 3.1", but then later on you say, "This module implements on purpose a little but useful difference that should not break the code of anybody". Apparantly it changes things enough that the tests do fail.
Please, see the doc about compatibility, or tell me what are the "minimal failures" you have found. I'm not interested in emotional belief, but real failures.
It seems to me it would be wise of you to shorten your reply messages and stick to talking about facts and reason instead of accusing everyone of being irrational and emotional. By including the line "I'm not interested in emotional belief", you must realize that you are going to provoke people and get exactly that... An emotional response!
All you have been doing these last few weeks is coming into our party telling us how much greater your party down the street is. When some of us try to tell you that we are quite happy here at our party we get a diatribe on why we are silly not to go to your party, since it has everything you could want ::Plus more. When you are told that the improvements don't look compelling or useful enough to move, you insult our intelligence by telling us we don't understand why your party is so much better.
If you want more people to use your modules, you are going about it in the wrong way. I would suggest you start writing some articles on how to use your modules, or write a bunch of applications that use your modules and show people how good it all really is over at your party.
As of right now, I'm not convinced yet, and it will take a lot more to get me to switch. Here is a short list of the reasons of why I will stick it out with the "hand-made-wooden wheels of several centuries ago" (quoted from the ::Plus docs in case any of you haven't read them yet):
- using accessors as lvalues is not important to me. You keep saying how great this is, but it's just a cool hack that doesn't serve me any real purpose (and it reduces performance since it uses a Tied scalar interface)
- CGI::Application is a very small module, so memory consumption is not an issue
- The new code is only 2 weeks old, so there is no way I am using it in production until it is more established
- You have added new dependencies to the modules where there were none before
- The code uses some strange structure that places semicolons at the start of the line which makes it insanely difficult to read.
- By abstracting the entire module using the OOTools modules the code becomes much more difficult to understand. You may not have that problem, since you also wrote the OOTools modules, but I certainly do.
- CGI::Application has a very large and established userbase to draw from
- The module installs a bunch of other modules regardless of whether they are useful or not (why do I need Apache::Application::Magic if I don't use Template::Magic or mod_perl?)
You have every right to put your modules on CPAN, and I don't think anyone here is trying to stop you. But I would like to politely ask you to stop browbeating us into getting us to use your modules. Feel free to stick around and suggest improvements to CGI::Application and to help users that need help with CGI::Application. But please realize that anyone on this list who was interested in switching to using your new modules has probably already done so. Myself and probably the rest of the users here will take a wait and see approach and stick with what we know works and works well.
So I would suggest you setup you own mailing list for your modules so that we can get back on track here with helping people use CGI::Application and working on the new features that we've been discussing in the last while. If you need help setting up a mailing list, just register a SourceForge project for your modules, and all that stuff will be setup for you automatically.
You seem to have enough time to respond to all the messages on this list, so instead of responding to this message, why not use the time to setup a new mailing list instead. I'm sure once you setup a new mailing list the people here won't mind if you send one more message to the list letting everyone know where it is...
Respectfully,
Cees
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
