Re: views on "Catalyst" by Jonathan Rockway ?

I appreciate all of this discussion as the publisher sent me
a copy of
the book so long as I agreed to post a review on Amazon and
my blog (it
will be on my OnLamp blog).

So far the review will be mostly positive, but the poor
editing is a
serious drawback.  I know Jonathan is a top-notch developer
with a
strong experience in Catalyst, so I was pretty sure that the
editorial
issues were not his fault and it's nice to have some
confirmation. 
Also, I'd love to find out why the publisher does not yet
host the
errata for the book.

--- Dave Hodgkinson <davehodggmail.com> wrote:

> > It really needs a couple  
> > more rounds of heavy editing.
> 
> Much like Catalyst...

What my review *won't* be is a review of Catalyst itself. 
It's a great
framework, but implementing plugins via multiple inheritance
is
frustrating.  I actually had one developer tell me (make
sure you're
not drinking anything when you read this) "we're
re-envisioning OO". 
Fortunately, Catalyst developers have realized that this
doesn't work
terribly well, so they now warn against this:

  http://tinyurl.com/33wofu
 
Of course, CGI::Application uses mixins, which is hardly
better due to
ordering problems.  Sigh.  Traits are *so* much better for
making stuff
like this work:

  http://tinyurl.com/yo2l9b

Cheers,
Ovid

--
Buy the book  - http://www.or
eilly.com/catalog/perlhks/
Perl and CGI  - http://u
sers.easystreet.com/ovid/cgi_course/
Personal blog - http://publiu
s-ovidius.livejournal.com/
Tech blog     - http://use.perl.or
g/~Ovid/journal/

Quoting Ovid <publiustemp-bondpmyahoo.com>:

> Also, I'd love to find out why the publisher does not
yet host the
> errata for the book.

Actually they do. It just takes a bit of finding. If you go
to

   http://www.packtpub.c
om/support

and choose the Catalyst book, you can then select the Errata
link,  
which opens up a new window.

Alternatively, you can just go to

   http://www.packtpub.com/view_errata/book/c
atalyst-perl-web-application

But they don't make it easy to work that out.

Dave...

On Feb 7, 2008 10:41 AM, Ovid <publiustemp-bondpmyahoo.com> wrote:
> I actually had one developer tell me (make sure you're
> not drinking anything when you read this) "we're
re-envisioning OO".

I am now wiping coffee from my monitor. :(

-- 
jeffa

On Thu, Feb 07, 2008 at 07:41:12AM -0800, Ovid wrote:
> What my review *won't* be is a review of Catalyst
itself.  It's a great
> framework, but implementing plugins via multiple
inheritance is
> frustrating.  I actually had one developer tell me
(make sure you're
> not drinking anything when you read this) "we're
re-envisioning OO". 
> Fortunately, Catalyst developers have realized that
this doesn't work
> terribly well, so they now warn against this:
> 
>   http://tinyurl.com/33wofu
>  
> Of course, CGI::Application uses mixins, which is
hardly better due to
> ordering problems.  Sigh.  Traits are *so* much better
for making stuff
> like this work:
> 
>   http://tinyurl.com/yo2l9b

And Moose's Role system (which is effectively 'traits on
steroids') better
still. Which is likely what we'll be using in the long run -
traits are all
very well but there are a fair few things you want method
modifiers for.

-- 
      Matt S Trout       Need help with your Catalyst or
DBIx::Class project?
   Technical Director                    http://www.shado
wcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or
deployment platform?
http://chainsawblues.vo
x.com/            http://www.shadow
cat.co.uk/servers/

On Fri, Feb 08, 2008 at 12:43:47PM +0000, Paul LeoNerd Evans
wrote:
>On Fri, 8 Feb 2008 11:10:23 +0000
>Greg McCarroll <gregmccarroll.org.uk>
wrote:
>
>> it had already became a bun fight.
>
>Am I the only one amuse by the irony of a discussion
about roles turning
>into a bun-fight?

On this group, it should probably be a pie-fight. 

But that just leads me to thinking about the alternate
ending of Dr Strangelove.

("Gentlemen, you can't discuss languages in here. This
is bond.pm!").

Ben

On Fri, Feb 08, 2008 at 12:44:22PM +0000, nigelturbo10.com wrote:
> Now trying to get things back on track ... I think
roles will be really 
> useful too as I often want to stuff things
"sideways" into an OO 
> inheritance hierarchy - but often the "ISA"
relationship isn't quite 
> right. Some objects just happen to "DO" the
same thing -- which is where I 
> think roles are handy.

"will be really useful" ?

Why future tense? http://search.cp
an.org/perldoc?Moose gives you them right
now in straight perl5 ...
 
> But in relation to plugins I think it's tricky for
roles to solve the 
> whole problem. The problem is the plugin may represent
only part of what 
> needs to be added to the software - config setting
changes may be required 
> as well - also conflicts with other plugins need to be
handled.

Well, for single-class plugins MooseX::Object::Pluggable
seems to work
fairly well - the role mechanism can already flag conflicts
although it
can't resolve them, and adding attributes (which can then be
introspected
by MooseX::SimpleConfig or MooseX::Getopt) can be used to
declare extra
data requirements.

The point at which it becomes trickier is when you need to
subclass
related classes or add complex data as well; IOC can help
make this sort
of thing more manageable but the code complexity cost annoys
me. Anybody
with a good answer for how to generalise this approach onto
a tree of
related classes/objects should speak up and I'll buy them
beer as thanks 

> Is it a pipe dream to imagine plugins slotting together
cleanly like lego 
> blocks? [1]
> 
> I was reading about "monkeypatches" the other
day [2] - and the idea of 
> modifying running code in-situ offers a somewhat scary
(from a security 
> point of view) but different take on the problem of
plugins working 
> together. Installing a plugin is less like lego and
more like applying a 
> software bandaid --- did it stick? Ok let's put another
one on. With the 
> ability to take some off as well.
> 
> 
> NIge
> 
> 
> [1] I think "webmin" has a brilliant
module/plugin format
> 
> [2] From wikipedia ... A monkey patch (also spelled
monkey-patch, 
> MonkeyPatch) is a way to extend or modify runtime code
without altering 
> the original source code for dynamic languages (e.g.
Smalltalk, 
> Javascript, Ruby, Perl, and Python).
> 
> 

-- 
      Matt S Trout       Need help with your Catalyst or
DBIx::Class project?
   Technical Director                    http://www.shado
wcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or
deployment platform?
http://chainsawblues.vo
x.com/            http://www.shadow
cat.co.uk/servers/

On 9 Feb 2008, at 13:13, Matt S Trout wrote:
> The point at which it becomes trickier is when you need
to subclass
> related classes or add complex data as well; IOC can
help make this  
> sort
> of thing more manageable but the code complexity cost
annoys me.  
> Anybody
> with a good answer for how to generalise this approach
onto a tree of
> related classes/objects should speak up and I'll buy
them beer as  
> thanks 


Class::Trait?

http://searc
h.cpan.org/dist/Class-Trait/

-- 
Andy Armstrong, Hexten