Re: Checking for required methods that were auto-generated by MooseX::AttributeHelpers

Even though it uses fancy syntax, Moose is still simple Perl code. Your code invokes Moose::has('ADJACENCIES',...), which creates get_adjacency. But as your code invokes with 'GSM::Cell::Role::BcchChecks' before it invokes the method creation, it will fail because that method does not yet exist.

I guess if Moose would first create a data structure instead of accessors, and then, upon for example, getting to the no Moose or __CLASS__->finalize() part, create everything in one go, the approach could be independent of the order of the declarations, something which I find less confusing. But as there are likely reasons for why Moose does and checks things immediately instead of requiring an explicit finalization step, this approach does not exist.

Comment on Re: Checking for required methods that were auto-generated by MooseX::AttributeHelpers Select or Download Code

Replies are listed 'Best First'.
Re^2: Checking for required methods that were auto-generated by MooseX::AttributeHelpers by stvn (Monsignor) on May 18, 2009 at 13:26 UTC
Yup, this is exactly correct it has to do with the order of the operations. I guess if Moose would first create a data structure instead of accessors, and then, upon for example, getting to the no Moose or __CLASS__->finalize() part, create everything in one go, the approach could be independent of the order of the declarations, something which I find less confusing. Unfortunately `no Moose` fires at compile time, so that is not really usable as a "end of class" marker. I also pondered a `__CLASS__->finalize()` type thing as well but forcing people to explicitly say "compose my class now please" is problematic in a highly dynamic language like Perl. It would also make runtime alteration of classes extremely tricky since the user would again be forced to say "okay, done with the alteration, please apply it". So while I don't 100% like the "compose as you go" approach we ended up with it does mean that at any given time in your program your classes are still valid. And while this does create some edge cases like this (most of them are role issues like this too) it also allows for a lot of other things to be possible. Everything has its trade offs. -stvn	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Checking for required methods that were auto-generated by MooseX::AttributeHelpers
by stvn (Monsignor) on May 18, 2009 at 13:26 UTC

Yup, this is exactly correct it has to do with the order of the operations.

I guess if Moose would first create a data structure instead of accessors, and then, upon for example, getting to the no Moose or __CLASS__->finalize() part, create everything in one go, the approach could be independent of the order of the declarations, something which I find less confusing.

Unfortunately no Moose fires at compile time, so that is not really usable as a "end of class" marker. I also pondered a __CLASS__->finalize() type thing as well but forcing people to explicitly say "compose my class now please" is problematic in a highly dynamic language like Perl. It would also make runtime alteration of classes extremely tricky since the user would again be forced to say "okay, done with the alteration, please apply it". So while I don't 100% like the "compose as you go" approach we ended up with it does mean that at any given time in your program your classes are still valid. And while this does create some edge cases like this (most of them are role issues like this too) it also allows for a lot of other things to be possible. Everything has its trade offs.

-stvn

[reply]
[d/l]
[select]