I never said that a Moose-based CGIP was out of the question.

I said a non-prototype-Moose base class would not be acceptable.

All you have to do is use a prototype-Moose base class, which either exists already, or is just a small matter of programming.

Or, you can go off and do what you want. Just don't call it CGI::Prototype until it's prototype-based.

Please don't misquote me. I never said that a Moose-based CGIP was out of the question. I said a non-prototype-Moose base class would not be acceptable.

Yes, that's right. I was typing in a hurry and made an overly general statement. My apology.

All you have to do is use a prototype-Moose base class, which either exists already, or is just a small matter of programming.

I would rather lean on standard Moose
1. so I can leverage all the Moose extensions that exist
2. so I dont have to worry about a splinter project and its potential bugs

Or, you can go off and do what you want. Just don't call it CGI::Prototype until it's prototype-based.

1. You should change your docs. You say that CGIP creates a CGI application by subclassing which implies class-based OOP
2. You should improve your docs (similar to my fork). When people scan your docs or your Linux magazine articles, they see nothing that cant be done just as easily with class-based OOP or CGI::Application. You need to motivate the unique position of this module with some exemplary sample code SOMEWHERE
3. Please embrace the multiple concepts of prototype. A CGI prototype could be something which prototypes the CGI request cycle. And CGIP does an excellent job of that, regardless of which object system it uses. There's no need for a separate distribution for something which has largely the same code.

So I can leverage all the Moose extensions that exist

is a false dichotomy. There should be nothing in a base class that's based on Moose plus prototype extensions that would interfere with any other Moose extension, except for perhaps a name collision in core methods.

You say that CGIP creates a CGI application by subclassing which implies class-based OOP

which again implies that you keep seeing "class-based" as the opposite of "prototype-based". I'm telling you that class-based is a subset of prototyped-based. And yes, the primary means of creating apps with CGIP is in fact subclassing the provided class, but as an additional feature, you can also use prototyped inheritance for some parts, which I have done, and would miss if not possible.

You need to motivate the unique position of this module with some exemplary sample code SOMEWHERE

No, I don't. This is not a popularity contest. I don't need to motivate anything. My code is happily powering websites all over the world for my clients. Any other use of it is pure gravy.

As I said, go ahead and call yours "MooseX::CGIP" or whatever. It just won't replace CGI::Prototype (even as a new version number) until it does replace it, including having easy access to unnamed subclasses and attributes that auto-populate in derived classes (named or unnamed) on being set. Those are both pretty trivial to do with Moose. But it needs to be part of the core of the CGI::Prototype replacement.

---

Update: See t/200_examples/006_example_Protomoose.t in the Moose distro.

-- Randal L. Schwartz, Perl hacker

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

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.

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?

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.

-- Randal L. Schwartz, Perl hacker

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.