Sorry, now to the whole list...
From: Stephen Howard <suppressed>
> > I disagree. I think that by adding new methods to C::A you just clutter it up.
> > We could end up with hundreds of new methods that just act as interfaces to
> > different contructors/methods of other commonly used modules (T::T,
> > CGI::Session, D::FV, etc). I find that 'explicit invocation of external
> > modules' makes the code very easy to follow since you know exactly where to
> > look for documentation about what is happening. Instead, if C::A implements a
> > interface (which would add one more method call to your object creation
> > costing you .00000001 sec) to another object, then the C::A docs would try and
> > explain things that that particular modules documentation explains.
>
> I actually don't feel that making a routine polymorphic adds discernable
> bloat. Then again, I'm a TT guy, and don't use load_tmpl
I don't feel that making a method polymorphic adds bloat either. What I was
objecting to was added a new method ('load_tmpl_scalar_ref()' I think). I also
think it unnessesary to try and rewrite load_tmpl() to handle every possible
way that H::T->new can be used. I think it was meant as a very simple
interface for the simplest case.
I too have used scalar refs, etc. If we just treat load_tmpl as a very simple
interface to H::T, then maybe we can decrease the coupling between H::T and
C::A. Don't get me wrong, I am a big fan of H::T and use it exclusively. But I
think that it might be hindering others from adopting C::A. I guess my real
question is 'Why should C::A reimplement H::T's new()'.
> > Instead of this, I think we should resume the discussion we had a few months
> > back about including some sort of plugin/registry/cleanup functionality to
> > C::A. Then when someone else requests this same kind of feature (just an
> > interface to another module) it can be implemented in it's own C::A::Plugin
> > style and not clutter up C::A itself.
>
> I'm afraid my own efforts on this got a bit derailed with my late
> shipment of Tuits. The code for Application::Pipeline is in pretty good
> shape though, and I hope to get back to getting it into CPAN shortly.
I think I may have forgotten a little of our discussion previously on this
issue, so forgive the perhaps obvious question. Is A::Pipeline designed so
that C::A will inherit from it and register it's own events in that pipeline?
Or is there some other purpose for it?
Michael Peters
Venzia
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/suppressed/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.