in reply to Re: creating a variable in an if statement ("do"s)
in thread creating a variable in an if statement

Your @f isn't accessible inside the if body.

Update: He noticed and posted a "fix" while I was posting, but the fix is also broken. @f doesn't equal @g as it should.

Replies are listed 'Best First'.
Re^3: creating a variable in an if statement ("don't"s)
by tye (Sage) on Jan 22, 2008 at 20:15 UTC

    Somebody who makes rampant updates to so many of their nodes after posting might want to check for updates (actually noted as such) from others before replying or, horror, wait a few minutes.1 :)

    1 I think it is unlikely that you started replying before my update was posted as I refreshed to see my update, then refreshed for other reasons and saw your node had been updated (with no notice) and you hadn't replied yet. So after my update you made your own update and then replied to my node based on a version from before your last update. But I give up trying to update/reply fast enough for you. I'll check back after a few hours and assume your node content won't expand several fold w/o comment (yes, I've seen that happen with your nodes more than once, as I've mentioned to you before) from that point and thus it might be safe to reply/update if any response is warranted. (:

    - tye        

      I didn't post the reply to your node after I noticed that you corrected yourself. What an odd thing to claim, since no one would gain from that. The delay was surely due to taking the time to verify that your solution didn't work before posting.

      By the way, the silent update to reply to the OP was to include code that accidentally wasn't pasted in from the editor I used to compose the reply. It happened as soon as soon as the browser showed me the posted node and before I looked to see if anyone else had posted other replies. (This time. I'm not denying other additive updates, but always before anyone replies.)

        I didn't post the reply to your node after I noticed that you corrected yourself.

        The more I look at this the more I can't figure out how you jumped to that conclusion after reading what I wrote. In particular, I said "then replied to my node based on a version from before your last update". If I had meant that you had posted after noticing my update, how would "[you] might want to check for updates [...] from others before replying" make sense? Or even "or, horror, wait a few minutes"?

        What an odd thing to claim

        Next time you think that, maybe you should delay replying to give your mind time to reflect and then re-read and see if your interpretation changes or your understanding improves.

        but always before anyone replies

        You can tell when some monk has started replying so that your silent updates don't make that monk's finished reply nonsense? Maybe you should consider having more patience before hitting "create" instead? Then there is just being polite to those who read your node before an update (and might be confused by a reply based on an update that they didn't notice, who might not want to reread your entire node doing a mental "diff" to figure out what you updated, or who didn't want to miss out on what you wrote since updates aren't (for good reasons) noted anywhere, etc.).

        It'd be nice if "preview" showed the (up-to-date) node that you are replying to, such as below the input box (moving the relatively new "In thread" and "In reply to" headers down there as well). After I had composed my previous reply I checked for updates before actually posting (as I did with this reply, also checking that what I wrote actually makes sense with what was written). I'd rather throw away a composed reply than post a useless one. But it'd be cool if "preview" would make that a trivial task. Though this (or some other) distraction to delay me pushing "create" usually serves me well.

        - tye