Re: a Moose CGIP shall not receive merlyn's blessing

[Bloodnok]

I can see merlyns point to some degree, however I've not used Moose (and have no immediate plans so to do) but surely, implementing CGI::Prototype as you suggest would introduce previously unneeded dependencies, on the part of existing code, on Moose i.e. removing any backward compatibility ... or have I, not for the first time, missed something otherwise obvious ?

Surely you should be reserving/creating a new namespace e.g. CGI::Prototype::Moose, to make the provenance abundantly clear to all and sundry - in a manner that the namespace CGI::Class doesn't.

[metaperl]

I can see merlyns point to some degree, however I've not used Moose (and have no immediate plans so to do) but surely, implementing CGI::Prototype as you suggest would introduce previously unneeded dependencies, on the part of existing code, on Moose i.e. removing any backward compatibility ...

Upgrading to the use of Moose would wreck backwards compatibility with any previous CGI::Prototype apps. However, note that you say: "implementing CGI::Prototype as you suggest". merlyn has no issue with Moose for a newer CGIP. He has an issue with standard Moose. So either of our approaches to adding Moose would cause this problem.

or have I, not for the first time, missed something otherwise obvious ?

The issue would be what new apps would run on. And, assuming that the new module with the new implementation is named something other than CGI::Prototype, then new code would simply use this different as its base class.

Surely you should be reserving/creating a new namespace e.g. CGI::Prototype::Moose, to make the provenance abundantly clear to all and sundry - in a manner that the namespace CGI::Class doesn't.

Well, initially I wrote such a module and planned for it to be part of the standard CGIP distro. But merlyn has made it clear that any standard Moose CGIP will not be in the CGIP distro, hence the name change.

I think using CGI::Prototype::Moose would make him uncomfortable and I certainly dont intend to narrow my approach to Moose forever. There were class-based OO before Moose and may be afterwards (though I doubt it).

Moose is the current chosen object layer for a class-based implementation of CGI::Prototype. I dont think the object layer itself need be in the module name. For instance both Catalyst and DBIx::Class are being re-implemented in Moose but retaining their current name. Likewise, I have a number of modules on CPAN that use Moose (e.g., Number::Closest) but the dont have Moose in their name.

Should Class::DBI have been named Class::DBI::Accessor::Fast?

[merlyn]

But merlyn has made it clear that any standard Moose CGIP will not be in the CGIP distro

If you keep misquoting me, I shall be compelled to keep correcting you. If you want the last word, stop misquoting me.

There's nothing "non-standard" about a Moose implementation that supports prototype style inheritance. I had a lengthy discussion yesterday on the irc.perl.org #moose channel about this very topic, and concluded that with a small amount of programming, you can get t/200_examples/006_example_Protomoose.t in the Moose distro into a trait rather than a base class, and it would support prototype-style inheritance and be compatible with nearly all of the rest of Moose.

So, please, stop your whining. You can use standard Moose, and add prototypes, and create a Moose-based CGIP.

Stop saying I'm making it impossible. I've just said I've done the footwork to prove it's possible. Now it's up to you to either comply, go your own way, or continue to look foolish.