* J. Shirley <[EMAIL PROTECTED]> [2008-04-27 23:45]: > On Sun, Apr 27, 2008 at 11:05 AM, Aristotle Pagaltzis <[EMAIL PROTECTED]> > 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/> _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/