[Catalyst] Bing!

[Matt S Trout]

On Fri, Aug 12, 2005 at 05:53:43PM -0700, Kyle Maxwell wrote:
> >
> >>* Rails dispatcher "routes" is flexible, as it has just recently  
> >>been rewritten.  As to the example Sebastian made of index.html  
> >>requiring a rewrite layer, in Rails, just put the index.html file  in 
> >>the public directory and it automatically is on your site.
> >
> >
> >Routes is a rewrite engine, like mod_rewrite, it doesn't change the  
> >fact that the core uri mapping depends on /class/method/arg1in Rails...
> >
> >I didn't meant a static file index.html, i meant a action.
> >
> >    sub index : Path('/index.html') { }
> 
> So what you are saying is that rather than manage your paths in one 
> config file, you'd like to be able to add paths in the controller?  That 
> sounds nifty, although there seems to be potential for two different 
> controllers/actions executing on the same path unintentionally.

It's more a question of giving controllers the ability to ask to handle
stuff rather than pushing them their handleable URLs. Makes for more easily
pluggable/re-usable code and is in the long run more powerful.
 
> I didn't look at your files, but Rails extentions typically require only 
> one additional line of code outside of the module that you are including 
> (which is just the normal class structure).

Except a lot of Catalyst extensions override bits of the request/response
process in order to change stuff. I'm not sure how you could do that with
"only one additional line of code" unless we're playing the s/\n/; /g; game :)
 
> >>* Multiple inheritance is considered an anti-pattern by many.  Ruby  
> >>supports module mix-ins, which give the benefits of multiple  
> >>inheritance without some of the drawbacks.
> >
> >
> >Guess you never heard of NEXT. (http://cpansearch.perl.org/~dconway/ 
> >NEXT-0.60/lib/NEXT.pm)
> >We use multiple inheritance as a kind of advanced AOP.
> >Think AspectJ without the static trigger points. :)
> >
> >Mixins are something completely different...
> 
> The link 404ed.  Multiple inheritance, and inheritance in general where 
> composition could be used, is frowned upon in some circles.  Maybe not 
> your circle, but that's ok.  I wasn't disapproving, jsut pointing out 
> the differences of opinion.  I know that mixins and MI are strictly 
> different, but they are used in similar ways for similar reasons.  If 
> you want MI, maybe mix-ins will be good enough.

If you want an example of what happens because of mix-ins seeming "good
enough", have a look at the mess that is the Class::DBI::Plugin namespace
on CPAN - mix-ins are fine until you need to stack/wrap them. Then you
need MI, but by that time you're already screwed.

But hell, I didn't learn this until I'd tried it in real life. I'll ask you
again in two years - maybe RoR devs simply don't want quite the insane
flexibility we require.

> I haven't yet found that level of separation to be useful.  I'm glad 
> that you do.  I suspect that you could probably separate out those 
> components of RoR and use them separately.  But it seems that its just 
> easier to distribute them all packaged, because no one wants to get them 
> separately.

I guess. Again, it's the difference between "you can use them separately if
you want" and "this is all designed to be used separately". It doesn't show
most of the time but when it does and your libraries aren't sufficiently
flexible you're screwed.

-- 
     Matt S Trout           Website: http://www.shadowcatsystems.co.uk
  Technical Director        E-mail:  mst (at) shadowcatsystems.co.uk
Shadowcat Systems Ltd.

 + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +