AGH. Silly mistakes
Thursday, March 18th, 2010 04:42 pmIn my attempt to conquer Bug 2344: Default View/Default filters should be default when adding from hover menu, I wrote this line of code:
What I thought it said:
* add this user to the filter
* once you've added the user, check whether it was successful, and keep a running tab on the status so you'll know in the end whether everything succeeded or not
What it was actually saying:
* once you've successfully done one thing (e.g., added the user to a filter or subscribed to that user), we're done. We don't need to do anything else (in this case, adding a user to the filter).
So now I've rewritten it more properly as:
(I got the boolean logic initially wrong too *rueful*)
This was an entire afternoon's worth of frustration (whyyyyyyy isn't it adding the user to the filter? Why doesn't it print out any of my warn statements within add_row? I didn't realize I wasn't calling it at all), solved with one of those flashes of insight you get when you get up and grab a glass of water and happen to reread your code when you get back.
$success ||= $filter->add_row( userid => $u->id )What I thought it said:
* add this user to the filter
* once you've added the user, check whether it was successful, and keep a running tab on the status so you'll know in the end whether everything succeeded or not
What it was actually saying:
* once you've successfully done one thing (e.g., added the user to a filter or subscribed to that user), we're done. We don't need to do anything else (in this case, adding a user to the filter).
So now I've rewritten it more properly as:
$success = $filter->add_row( userid => $targetu->userid ) && $success;(I got the boolean logic initially wrong too *rueful*)
This was an entire afternoon's worth of frustration (whyyyyyyy isn't it adding the user to the filter? Why doesn't it print out any of my warn statements within add_row? I didn't realize I wasn't calling it at all), solved with one of those flashes of insight you get when you get up and grab a glass of water and happen to reread your code when you get back.
no subject
Date: 2010-03-19 03:23 am (UTC)And for context, wrt to Java, Java doesn't have the "a ||= b" ( a = a OR b ) but it does have some of the other forms: a += b (a = a+b), a-=b, etc.
no subject
Date: 2010-03-23 02:40 pm (UTC)Probably at least partly because it would be much less useful in Java -- first off, the logical operators only work on boolean-typed variables, and even in C, where you don't have this (well, you don't even have a boolean type in the first place), the return value of && or || is always 1 or 0, whereas in Perl, the "true" return value of || is the first operand.
So in Perl, if you have $a with the value 5, when $a ||= 7 would have $a still containing 5 afterwards, whereas in C, a = a || 7 would have a contain 1 afterwards ("true").
(So ||= is sometimes used to initialise a variable that may not be initialised -- "Use this as the default value, unless the variable has already been assigned a value before, in which case keep that." Which doesn't work if the variable has been explicitly assigned a value of 0, "0", or "", which is why newer Perls have a separate operator for that, //=, which tests for "contains the undefined value" rather than "contains a false value".)
no subject
Date: 2010-03-23 03:09 pm (UTC)Yup! I didn't go into it further, though, because the person I was commenting to knew Java but not Perl (so going into the difference between Java and Perl might have been counterproductive).
ETA: I didn't realize that about newer perls, though! Perl 6?
Also, as an aside, I ran into another issue later on (another patch), when I got to focusing on the default assignment side effect of ||=, like so:
%hash = %$a || func_which_returns_a_hash();
That gave me: ( "1/8" => undef )
Eventually figured it out, but man, threw me for a loop *g*