[Catalyst] Re: So, what do we want in the -next- book?

[J. Shirley]

On Sun, Apr 27, 2008 at 5:19 PM, Aristotle Pagaltzis <pagaltzis at gmx.de> wrote:

>  I'm not talking about COMPONENT. I'm talking about classes with
>  accessors for which they never set a value themselves. I don't
>  remember specific examples since it was two or three weeks ago,
>  but it had to do with the dispatcher, and I stumbled this way in
>  two or three places when I didn't have time to read the entire
>  source, so I gave up and switched to a different approach.
>
Agreed on some parts, but it is getting better.  That's the sort of
thing that is "patches welcome" and I think the Moose work will help
that (or hurt it, I suppose we'll have to see).  5.8 ftw!

>
>  > While I agree that the design (in terms of pure OO) isn't the
>  > best, it does work and I think it does make plenty of sense. If
>  > you look at the debug output on server startup, you can easily
>  > figure out what is being loaded and how.
>
>  Yes, as I said, one can certainly figure out the code. There's
>  just no reason it couldn't and shouldn't be easier, and I mean
>  for those who are willing to read source. I say so particularly
>  because it's not as easy as it should be to understands parts of
>  Catalyst in isolation.
>
I guess my point is that in my experience with similarly complex code
bases, I've found Catalyst better than average in nearly every aspect.
 There are a few rusty nails poking out, but by and large one can get
a good overview just by reading Pod (I think that
Catalyst::Manual::Internal and ::ExtendingCatalyst give most of what
people would want to know).

>
>  > My point is that people may think they need to understand the
>  > codebase when in fact they just need to not be lazy and write
>  > better code.
>
>  That seems a little weird, but I think I can follow the logic,
>  and if I am following, then that is true, but not directly
>  relevant to my (itself tangential) point.
>
>
I wasn't really sure what your point was, but the second email
clarified some points.  My point is that the market for people who
actually _need_ (or, have the aptitude to properly grasp what they are
learning) is minuscule.  The vast majority want to write better
applications, but you don't need to know the details of the tool you
use in order to utilize it well.  Anything that can be done to debunk
the mysticism of Catalyst is a good thing, in my opinion.  Far too
many people hold the opinion Catalyst internals do something magic
when in reality it is just perl.  Aside from some of the accessors
that you've brought up earlier, and the method attributes, everything
is quite straight forward.  People still don't _need_ to know this
stuff to write killer applications.  What they _need_ to know is how
to write good code, and that is a separate issue from Catalyst.

>  > If a user wants to know the internals without reading any code,
>  > they are lazy. Pure and simple.
>
>  If they want to know in detail, sure.
>
>  Are you also saying they *should not* even *want* to have an
>  overview of the architecture if they are not interested in every
>  last detail?

I think they're two separate things.  An overview of what
architecture?  The dispatch cycle or initialization?  What MVC really
means?  Why you shouldn't write a plugin?  Too many questions and far
too many answers, many of which are opinions.

>
>  > This thread is about what goes into the next book. […] To think
>
> > that the internals need a deadtree version, that's silly.
>  > Internals should be in .pod; for developers by developers --
>  > not users.
>
>  OK, yes, that got mixed up a bit. I wasn't really arguing about
>  the book; mainly about the fact that there needs to be more and
>  better POD. I certainly do NOT mean that the internals warrant an
>  entire dedicated book. However, it would definitely make sense to
>  have a chapter on the internals in a Catalyst book. If it was a
>  generic Perl webapps book, then I agree it doesn't make sense for
>  that.
>

If there is a next book, I can see an Extending Catalyst chapter but I
still don't see the need for an Internals.  Outside of the
initialization steps and component base classes, I don't think it
would help many users.  I tend to see Extending Catalyst as a very
very separate thing than Internals though, mainly because I hope one
can extend Catalyst without ever having to read Catalyst source.
That's a separate mailing list thread though (which, afaik, doesn't
exist).
>
>  > Then you call it laziness blame.
>
>  That was not about the book at all. Sorry for the confusion.
>  I was addressing the oft-repeated assertion that users who ask
>  for an architectural overview should just man up and read the
>  source.
>

I suppose my statements on the contrary are more along the lines of
"Read the POD first".  If they have questions after that, I think many
people would be happy to answer them in exchange for some pod patches.
 I think that there should be a completely documented manual segment
about extending Catalyst.  But for Internals... you can't know it
without reading the source, and I think that's the way it should be.
If someone wants to know the internals, I think they'd be hacking on
core in some regard which is different than extending Cat, so I'm
basing my opinions and thoughts on the matter purely on what the end
goal of the user is likely to be.

So, for the next book I heavily endorse a chapter on Extending
Catalyst which should cover overview information specific to Catalyst.

Hope that clears everything up :)