[Catalyst] Re: Why does $c->stats require -Debug flag?

Aristotle Pagaltzis pagaltzis at gmx.de
Fri Apr 25 00:04:49 BST 2008


Hi Wade.Stuart,

* Wade.Stuart at fallon.com <Wade.Stuart at fallon.com> [2008-04-25 00:30]:
> Aristotle Pagaltzis <pagaltzis at gmx.de> wrote on 04/24/2008 12:32:12 PM:
>> * Jonathan Rockway <jon at jrock.us> [2008-04-24 19:10]:
>>> * On Thu, Apr 24 2008, Aristotle Pagaltzis wrote:
>>>> * Jonathan Rockway <jon at jrock.us> [2008-04-24 11:25]:
>>>>> * On Thu, Apr 24 2008, Jon Schutz wrote:
>>>>>> No problems, if that's what the Catalyst standard says; I
>>>>>> must have missed it. Where is it? I'd like to consult it
>>>>>> on a number of matters... please post the link.
>>>>>
>>>>> Basically it's more of a "zeitgeist" than an actual
>>>>> document. There are some things that the community has
>>>>> decided and "just do".
>>>>
>>>> That?s the sort of feel-good bollocks I?d expect to read on
>>>> a Rails hype blog, not here. Unspoken rules and gut feel are
>>>> no way to run a community. Catalyst suffers from this in
>>>> general: way too little is written down, much less in any
>>>> systematic fashion.
>>>
>>> Nobody has time to run a bureaucracy.  We just want to write
>>> code.
>>
>> Yes, backcompat code. And I suppose the time to run a
>> deprecation cycle bureaucracy will find itself. File under
>> ?false laziness.?
>
> If you expect behavior over cycles, write test code.  If
> changes happen that make that test fail it will prompt
> discussion and offset the depreciation cycle to the closest
> change set.  If you want to document down to the dot,  without
> test code -- you are in for a world of outdated documentation.

I am not even talking about code docs here, I am talking about a
short note about the project’s conventions. Something like the
`Documentation/CodingStyle` document in the Linux kernel source,
except appropriately scaled down since Catalyst is so much
smaller in terms of both SLoC and contributor count.

It doesn’t have anything to do with bureaucracy, I’m talking
about one, maybe two pages of bullet points about the most
important guidelines of the project. “Methods without docs are to
be considered internal,” “leading underscore in a documented
method name means it’s OK for subclasses to touch but not
outsiders,” “all patches must be accompanied by tests” etc etc,
that sort of thing. Not a law code, just a summary of how things
are done ’round here. In fact it *mustn’t* be too elaborate and
intricate, else it won’t get read.

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



More information about the Catalyst mailing list