search

rjbs / Pod-Weaver

recombine pod documents into awesomer pod documents
26 stars 28 forks source link

Fix for extracting module names from MooseX::Declare-style classes #9

Closed barefootcoder closed 12 years ago

barefootcoder commented 12 years ago

When using Pod::Weaver on code that utilizes MooseX::Declare, Pod::Weaver::Section::Name and Pod::Weaver::Section::Version cannot find the name of the module. This is a patch that fixes that issue.

The patch is in 3 commits: first a failing test, second a simple fix, then a refactoring which extracts the common functionality. If you don't like the refactoring, just toss that final commit; the patch works perfectly well without it.

I'm happy to rework the patch in any way you see fit if there's anything about it that isn't up to snuff. Just let me know.

rjbs commented 12 years ago

I'll look more at this commit again later, but in brief: I am not very enthused about the precedent of dealing with MooseX::Declare classes this way.

barefootcoder commented 12 years ago

I am not very enthused about the precedent of dealing with MooseX::Declare classes this way.

If you have a better suggestion, I'm certainly open to it. I could subclass Pod::Weaver, of course, or monkey-patch it. But the fix is so simple that it seems a shame not to just let Pod::Weaver handle it directly. Perhaps some option or configuration that enables it?

I do think MooseX::Declare classes deserve to have the same benefits that other Perl classes have. Is there a specific objection you have to handling them this way? As I say, I'm open to reworking the patch however you see fit.

barefootcoder commented 12 years ago

So, I'm guessing that I need to look at reimplementing this as a subclass. Would you like to weigh in on a potential name? Pod::Weaver::Class or somesuch?

rjbs commented 12 years ago

Sorry for the long-delayed reply.

My preference is to stick to parsing "plain old Perl" insofar as such a thing exists. i.e., the kind of thing PPI could be expected to handle. I would rather not try to handle things like source filters and syntax extensions.

I wouldn't mind having a mechanism by which these extensions could hang directives for extra scanning into Pod::Weaver, etc., but I don't want to start plugging them in willy nilly.

If I were to implement these things as subclasses, I'd name them things like Pod::Weaver::Section::Name::MXD. But I'd probably try to figure out the right generics API instead.

barefootcoder commented 12 years ago

Thanx for getting back to me. I think I will go ahead and create Pod::Weaver::Section::Name::<something> ... I'm not sure MXD is the right thing to use there, because technically that's an implementation detail. I.e., some other module could easily implement a class keyword and this module wouldn't care; it would still work fine.

If you ever get inspired to create the generic API you mentioned, and you find the time to do it, please let me know: I'd be pleased to be involved.

Thx again for the awesomeness that is Dist::Zilla & friends.