Re: MooseX::OmniTrigger

Damn, sorry about that pile of caps.

-----Original Message----- 
From: Todd Lorenz
Sent: Thursday, December 22, 2011 3:29 PM
To: Karen Etheridge ; [email protected]
Subject: Re: MooseX::OmniTrigger

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++