Re^2: Simple Mouse/Moose question

>>Pretty much any time you want the builder/default of one attribute to have access to the values of another attribute, you want to use lazy. The order of attribute initialization in Moose (and Mouse) is undefined (basically hash-order).

Okay, but that is not what is going on in my example. There is only one builder method; the second method is called via the modifier "after" which guarantees do_n() already happened. Ie, do_n2() is only called "after" do_n().

The problem does not matter much since there are other ways to accomplish the goal (eg, assigning do_n2() as a lazy builder method works). It just makes me suspicious of the use value of the Moose style method modifiers: if I assign an "after" method but changes made to the object in the triggering function have not take place when its "after" method is called, does that not make using such a method modifier very problematic???? Eg, from Moose::Manual::MethodModifiers:

Similarly, an after modifier could be used for logging an action that was taken.

I guess it could be used, but let's say the action taken was that a string value was changed, and I call an after modifier method to record the change -- BUT the value is still the same as it was prior to to the action that "was" taken, then how can this modifier method log the change correctly?? It will record the previous value, not the new one, since the object it receives does not reflect assignments made in the method it "modifies after".

Comment on Re^2: Simple Mouse/Moose question

Replies are listed 'Best First'.
Re^3: Simple Mouse/Moose question by stvn (Monsignor) on Feb 24, 2011 at 15:50 UTC
Okay, but that is not what is going on in my example. There is only one builder method; the second method is called via the modifier "after" which guarantees do_n() already happened. Ie, do_n2() is only called "after" do_n(). The problem does not matter much since there are other ways to accomplish the goal (eg, assigning do_n2() as a lazy builder method work Okay, I see what you are saying and I see what the issue is now. So what is happening is that the builder method `do_n` is being called, and the return value of that method is then taken an assign to the 'n' slot. Your method modifier is called after the builder method, meaning, it happens before the actual slot assignment, hence 'n' always being null. I usually don't recommend using method modifiers with things like builders since it can get very hairy and really, that is what lazy & default/builder are for (as you discovered with your lazy_builder solution). It just makes me suspicious of the use value of the Moose style method modifiers Well, there are plenty more uses then just this :) If I assign an "after" method but changes made to the object in the triggering function have not take place when its "after" method is called, does that not make using such a method modifier very problematic???? Yes it would, but as I pointed out above, the modifier didn't fire after, it fired before. The builder method is not the right place to wrap this stuff. Moose does not perform any magic in this sense, if you have assigned the slot (or called the accessor to assign it for you), then the change will be there. I think this was just a simple misunderstanding of when builder is fired in the chain. I guess it could be used, but let's say the action taken was that a string value was changed, and I call an after modifier method to record the change -- BUT the value is still the same as it was prior to to the action that "was" taken, then how can this modifier method log the change correctly?? It will record the previous value, not the new one, since the object it receives does not reflect assignments made in the method it "modifies after". It is outside of the responsibility of Moose to decide if your value actually changed or not, Moose only knows (and only cares) that you called a method, PERIOD. If you want this kind of thing you will need to write it yourself on top of Moose, as a MooseX:: module perhaps, but it most certainly does not belong in Core Moose, if for nothing more then the notions of equality are not universally agreed upon. -stvn	[reply] [d/l]
Re^3: Simple Mouse/Moose question by ikegami (Patriarch) on Feb 24, 2011 at 16:02 UTC
the second method is called via the modifier "after" which guarantees do_n() already happened. Where do you see do_n assigning anything to "n"? As I explained, "after do_n already happened" is too soon. The "trigger" is "as soon as it returns". `$self->{n} = sub { my ($self) = @_; my $rv = $self->do_n(); $self->do_n2(); # Too soon return $rv; }->($self);` [download]	[reply] [d/l]