Perl-Sensitive Sunglasses | |
PerlMonks |
Re^3: a Moose CGIP shall not receive merlyn's blessingby merlyn (Sage) |
on Oct 20, 2009 at 16:01 UTC ( [id://802257]=note: print w/replies, xml ) | Need Help?? |
So I can leverage all the Moose extensions that existis 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 OOPwhich 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 SOMEWHERENo, 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.
In Section
Meditations
|
|