in reply to if/unless and chaining

Bah. Confusing, would sum it up IMO. DeMorgan's Law was never fun in circuits (why use NOR, and NAND gates, when they made AND and OR gates), which leads me back to Perl and why would one confuse oneself with something unnecessary when the same functionality can be gotten less confusingly?

Assuming I have things that have more than one condition, lets say colors = (Red blue green) and sizes (small medium and large) and luster (shiny dull). Now 

unless ( 
         size eq small and 
         color eq red and 
         luster eq dull
       ) { do_something}
elsunless ( luster eq dull ) { do_something else}
else {do_a_totally_different_thing)

[download]

So the unless does everything but small red dull things. the elsunless does whatever is left but dull things. So there would still be small dull red things for the else to deal with (I hope my logic is sound, as I mentioned above confusing). So from my understanding of my sequence of events it would be easier to just say:

if ( 
     luster eq dull and 
     color eq red   and
     size eq small
    ) {do_a_totally_different_thing)
elsif ( luster eq shiny ) { do_something_else }
else { do_something }

[download]

I hope that my logic is not so flawed, as to have my point missed among my errors. And I would be happy to revise this if it is messed up.

Anyhow, now that I have thoroughly confused myself I will, shutup.

-enlil

Replies are listed 'Best First'.
Re: Re: if/unless and chaining
by jryan (Vicar) on Nov 06, 2002 at 07:53 UTC
    DeMorgan's Law was never fun in circuits (why use NOR, and NAND gates, when they made AND and OR gates)

    1. NOR and NAND gates are cheaper than OR and AND gates; OR is implemented with a NOR followed by an inverter (NOT), and AND is likewise implemented with a NAND followed by an inverter. This saves on the delay and cost of the extra inverter.
    2. It is possible to implement any circuit with only using NANDs, or only using NORs. The same can't be said for AND and OR.
[reply]
Re: Re: if/unless and chaining
by John M. Dlugosz (Monsignor) on Nov 06, 2002 at 04:36 UTC
    Demorgan's law avoidance is why I like unless. In this simple case, you can reverse eq to ne while chaning unless to if, so it's still simple.

    But if the condition is complex, putting a ! in front of the whole thing means more parens  if (!( ...real stuff )) { ... and I don't like the extra layer with only one char outside them! Reversing the Real Stuff would mean changing ands to ors and inverting whatever, and is easy to mess up. Plus I'd rather express it the way that's closest to the problem domain.

[reply]
[d/l]
      One could always just have another variable set to 1 (say $matched_already=1 )outside the first condition and then set to 0 if it passed into the initial unless block. A second unless in the chain would be considered only if: 
      unless { second_condition or $matched_already } { do_something_else}

      [download]

      and so on. . . Granted you won't get the nifty optimizations that come with the if/elsif/else structure where the subsequent elsif/else conditions are checked only if the previous if/elsif conditions all failed, but no extra parens. But for the same reasons you stated ..

      Reversing the Real Stuff would mean changing ands to ors and inverting whatever, and is easy to mess up

      , I think the elsunless would be another layer of complexity that I for one would have to stop the flow of code flowing from the fingers to grab a piece of paper to be able to gather figure what exactly I was excluding in every case, in all but the simplest cases where I would have used the unless/else or if/elsif/else structure anyhow. Then again at the moment I am hard pressed to think of one instance (I have pondered this for a couple of hours already), where an unless/elsunless/else structure would be more natural than its if/elsif/else counterpart. (though, I guess like most logic is a subjective matter)

      -enlil

[reply]
[d/l]
[select]

In Section Meditations