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

[Aristotle Pagaltzis]

* J. Shirley <jshirley at gmail.com> [2008-04-27 23:45]:
> On Sun, Apr 27, 2008 at 11:05 AM, Aristotle Pagaltzis <pagaltzis at gmx.de> wrote:
>> As I try to make sense of the codebase I keep stumbling over
>> places where the setup is quite incestuous: components often
>> do not really set themselves up, they are just glorified
>> structs that expect whoever instatiates them to do all the
>> work. Which expectation is nowhere to be found in the docs –
>> so much for "well documented." In OO design terms, this is
>> really crummy.
>
> Funny, I think that new vs. COMPONENT time is pretty well
> documented. There is a document for Internals.
> http://search.cpan.org/~mstrout/Catalyst-Manual-5.701004/lib/Catalyst/Manual/Internals.pod

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.

> 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.

> 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.

> 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?

> 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.

> 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.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>