Re: [cgi-prototype-users] Creating mixins for CGI::Prototype

[Andrew G. <ag...@bu...>]

On 8/16/07 1:32 PM, "Randal L. Schwartz" <me...@st...> wrote:

>>>>>> "Andrew" == Andrew Gianni <ag...@bu...> writes:
> 
> Andrew> Dotan, that looks like what I'm looking for and it's roughly what I
> Andrew> had in mind although I didn't realize that a Class::Prototyped class
> Andrew> could have multiple parents, which resolves the question of multiple
> Andrew> mixins. How are they evaluated for execution? For example, if you
> Andrew> override render_enter in Miner::Utils::Links and Miner::Utils::Text,
> Andrew> will it just execute both of their render_enter methods in sequence in
> Andrew> the order you added their parent slot in the foreach loop of
> Andrew> install_mixins?
> 
> No, it picks "first found", which actually makes mixins a bit of pain.  That's
> why there's that particularly tricky code in that one project I did for you,
> to essentially insert the "mixed-in" version in the middle of your inheritance
> ladder, rather than hanging out on a second parent.

Right, and that's actually what I'm looking for. In some cases, I need to
insert an abstract page class between my app class and a concrete page class
implementation. Sometimes, I need to insert an abstract class between my app
class and CGI::P::H. After staring at your code for a while it makes sense,
I just need to pick it up and move it somewhere more generally useful.

Dotan, are your mixins simply providing additional non-CGI::Prototype
functionality, i.e. not overriding core CGI::P methods?

> It's one of the weakest parts of the Class::Prototyped design, unfortunately,
> and having chosen that for CGIP, I'm sorta stuck with it.

So the upshot is that the developer needs to be aware of what the mixins are
doing and where there could be potential conflicts. As long as mixins call
reflect->super we should be in relatively good shape, right? But there may
be places where we don't always want to call super at all depending on the
functionality, which may cause unexpected results. Does this mean that
mixins probably won't be a good option for general CPAN modules, but only
for local classes that the developer understands the internals of? Or should
mixins only be restricted to core methods that *always* call super?

Andrew

-- 

Andrew Gianni - Lead Programmer Analyst
University at Buffalo, State University of New York
Computing and Information Technology / Administrative Computing Services
215 MFAC, Ellicott Complex, Buffalo, NY 14261-0026
716.645.5332 - AIM: andrewsgianni - http://www.newkenmore.com/agianni