No commit bit, but I'll be happy to write the tests as tickets.
Regarding that "BUG #1", I made a note in OmniTrigger.pm:
THERE'S A SPECIAL CASE, WHEN WE'RE HERE AS THE RESULT OF A SLOT BEING SET
DURING FIXUP
FOR THE PURPOSE OF "TRANSFERRING" A VALUE FROM THE "OLD" INSTANCE TO THE
"NEW." WE
DON'T COUNT SUCH A TRANSFER AS A *CHANGE*: IT'S JUST BOOKKEEPING. SO FOR
THESE
TRANSFERS WE NEITHER FIRE THE OMNITRIGGER NOW NOR SET
fire_omnitrig_when_ready TRUE
FOR A FUTURE FIRING.
KLUDGY SOLUTION, THE unless CONDITION, HERE. I FINALLY HAD TO DO SOMETHING
LIKE THIS
BECAUSE OF THE WAY _fixup_attributes_after_rebless IS IMPLEMENTED. THERE ARE
BASICALLY
THREE DIFFERENT SCENARIOS THERE: 1) EXISTING VALUES OF ATTRIBUTES WITH
UNDEFINED
init_argS ARE TRANSFERRED VIA set_value; 2) EXISTING VALUES OF ATTRIBUTES
WITH DEFINED
init_argS ARE TRANSFERRED VIA set_initial_value; AND 3) NEWLY INCOMING
VALUES FOR
ATTRIBUTES WITH DEFINED init_argS ARE SET VIA set_initial_value. WE NORMALLY
FIRE
OMNITRIGGERS FOR ANY USE OF set_value OR set_initial_value (RATHER,
_set_initial_slot_value, ULTIMATELY), BUT HERE OMNITRIGGERS SHOULD FIRE ONLY
FOR THAT
THIRD SCENARIO. AS MOOSE GIVES NO WAY EXPLICITLY TO ISOLATE "SET-FOR-THE-
PURPOSE-OF-
TRANSFER" OPERATIONS, WE'VE GOT TO ISOLATE (AND AVOID) THEM MORE
CIRCUITOUSLY.
The bug is scenario #1, above -- calling set_value entails a trigger call.
-----Original Message-----
From: Karen Etheridge
Sent: Thursday, December 22, 2011 2:55 PM
To: [email protected]
Subject: Re: MooseX::OmniTrigger
On Thu, Dec 22, 2011 at 02:36:00PM -0700, Todd Lorenz wrote:
Hi, Karen, sure. I should say I *suspect* they're bugs based on my
expectations of trigger behavior. I should also say they're extremely
minor
and probably aren't affecting anyone anywhere.
They're in mooseisms.t. My explanation of #2 is pretty flip -- I didn't
figure anyone would ever actually read it. Let me know if it needs
translation.
Using:
https://github.com/trlorenz/MooseX-OmniTrigger/blob/master/t/007-mooseisms.t
# POSSIBLE MOOSE BUG #1. DURING A REBLESS, REGULAR TRIGGERS WILL FIRE FOR
# ANY ATTRIBUTES THAT HAVE AN UNDEFINED init_arg AND BEGAN THE REBLESS WITH
# A VALUE.
This sounds suspiciously similar to a fix I made for 2.0009: "When an
object is reblessed, triggers are called on attributes that are set during
the reblessing." To clarify, triggers were not called for attributes that
were being *added* (initialized, or altered) during the reblessing, as
rebless() allows the supply of additional constructor arguments -- but
possibly this is a red herring and there is no connection.
I've confirmed this behaviour with my own tests, and indeed the attr must
have init_arg=>undef for the trigger to fire during a rebless. IMHO this
is definitely a bug and should be fixed.
#2 also sounds like a real issue (it is long so I won't repeat it here).
Todd, do you have a Moose commit bit? It would be of significant value if
you were to commit some TODO tests to the Moose repository so these issues
were documented, and/or write them up as separate RT tickets. (You can
submit your ssh public key via the instructions in
Moose::Manual::Contributing, or hop on irc.perl.org #moose.)
--
"I do not fear computers. I fear the lack of them." - Isaac Asimov
. . . . .
Karen Etheridge, [email protected] GCS C+++$ USL+++$ P+++$ w--- M++
