search

davehouston / ClassMopper

A Pod::Weaver plugin using Class::MOP for naval gazing
5 stars 4 forks source link

Can't locate object method "get_all_attributes" via package "Moose::Meta::Role" #1

Closed russoz closed 13 years ago

russoz commented 13 years ago

Hi Dave,

It seems the Moose folks changed the method name in Moose::Meta::Role, and that broke the ClassMopper. I have not gone through the history to where and when that happened, nor have I tested it much, but it seems like a simple change.

I have forked this repo: if you would like me to send a pull request with an update, just let me know.

Cheers, Alexei

russoz commented 13 years ago

BTW:

Can't locate object method "get_all_attributes" via package "Moose::Meta::Role" at /home/az/perl5/lib/perl5/Pod/Weaver/Section/ClassMopper.pm line 82.

davehouston commented 13 years ago

By all means, pull-request-away. I'll get on it asap.

russoz commented 13 years ago

I've tried to replace locally the call to get_all_attributes for get_attributes_list, which seems to be the name for that feature now, but I got a different error now. Will have to dig a little bit deeper into this, and I haven't had all that contact with Class::MOP internals yet. I have started using Moose a couple of months ago, and Dist::Zilla + Pod::Weaver a couple of weeks ago, so don't hold your breath.

russoz commented 13 years ago

Dave, I have been debugging it, and it seems to be happening ONLY with Moose::Role's - that explains how the Mopper passed the test - it uses only a class.

I read a fair amount of documentation in the Moose::* and Class::MOP::* namespaces, and the get_all_attributes() returns the list of objects you already use, but the get_attributes_list returns only the attribute names. More than that, it seems that the Moose::Role internal representation of the attributes is just a hash, not a blessed object. So, the bottomline is: we need a whole different implementation when talking about Moose::Roles - and that sucks. It SHOULD the same stuff inside.

So, to make sure I can at least generate some docs, I added some code to prevent ClassMopper from fussing into roles.

That prevented the reported error from happening. However, I found out something else: Dist::Zilla does not seem to set up @INC with a path that contains the module "lib/" or the building directory BEFORE running the Pod::Weaver. Thus, I got errors like:

Can't locate DataFlow/Node/FileInput.pm in @INC (@INC co ...

I added './lib' to PERL5LIB and voilá, it worked.

russoz commented 13 years ago

I am going to send you the code that prevents ClassMopper from running against roles, so that we can be safe Pod::Weaver-wise. Then we'll need to think of some way to get the roles' information.

davehouston commented 13 years ago

Hm.

You could argue that a Moose::Role isn't really something that should be documented by an automagical introspection thinger like ClassMopper.

While it's bad that it breaks via exploding instead of maybe a warning or an empty section, the reason ClassMopper providers the 'Method originates in ...' bit is to allow the consuming class to point to documentation in roles, parent classes, etc. (on a related note, should update that to a link instead of plain text..)

russoz commented 13 years ago

From a documentation POV, I don't really think there should be any such distinction. I mean, it makes no sense to me to have all the classes introspected automagically, but those roles over there? oh no, you will have to keep manually dragging the iron balls around (documentation-wise).

IMHO, the Moose::Meta::Role implementation, as far as I could figure it out, sucks. It looks like one of those pieces of code that were made to make their own life easier, rather than the life of the ones who are going to actually use it.

(agreed on the link stuff ;-) )