Given possible states A,B,C,D and the if-elsif-else structure

      if( state equals A) { Take action1 }
   elsif( state equals B) { Take action2 }
   else                   { Take action3 }
[download]

any given state will cause exactly 1 action to be taken no matter what the value of state.

However using this

    unless( state equals A ) { Take action1 }
elsunless( state equals B ) { Take action2 }
else                        { Take action3 }
[download]

If the state is C or D, by the logic of the statements, actions 1 and 2 would need to be taken; but as the entire block terminates once one condition succeeds, action2 would only ever be performed if the state was A, which is counter-intuative to say the least. Also, when would the else clause be performed?

Effectively, the structure above is equivalent to

   unless( state equals A) { Take action1 }
   elsif ( state equals A) { Take action2 }
   else                    { Take action3 }
[download]

which is already legal in Perl, but is actually the same as

   unless( state equals A) { Take action1 }
   else                    { Take action2 }
[download]

As action three will never be taken as every state except A will have caused action 1 and then the contruct terminates.

    unless( state equals A ) { Take action1 }
elsunless( state equals B ) { Take action2 }
else                        { Take action3 }
[download]

the middle line is the same as

elsif (state != B) ...
[download]

I agree, don't do that. But not every chain of if/elses is a simple switch statement. I can be testing a number of variables or aspects of the total state, making successively tighter constraints. Think of an && chain with side-effects on each test.

I may be wrong about this, but I think that the example above logically doesn't make sense. The second conditional statement, elseunless(state equals B) will only be reached if the first conditional is true, i.e. state equals a. Effectively the second test will never be true, because when the state equals b, action 1 will be taken.

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

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.

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.

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

Because unless should only ever be used as a statement modifier:

    die "Tough beans.\n"
        unless  isValidUser();
[download]

I worked for a long time coding Pop-11, a language which did have an elseunless to go along with its unless.

Never caused any problems in my experience.

Wasn't used a huge amount either - but I think it did increase the clarity of some code where it was used.

Personally I think that the argument for consistancy wins over the argument against due to confusion - the fact that we have to continually explain why there isn't an elseunless might be considered a clue :-)

the fact that we have to continually explain why there isn't an elseunless might be considered a clue

That's no way to argue. Common Beginner Mistakes points out a couple things that are often asked about - but it's plainly obvious that folks asking for them a lot doesn't make them desirable.

Note I'm not specifically arguing against an elsunless - I'm just saying that the fact it's oft asked about doesn't constitute any evidence for anything other than that it's oft asked about.

Makeshifts last the longest.

I completely agree that it is not conclusive proof, but it's not completely irrelevant either. I guess my usability / user-centric design hat is showing :-)

The fact that novices expect there to be an elseunless, or (to pick another example) expect length to work on arrays and hashes, are evidence that there is confusion.

In some instances the confusion is due to misconceptions and missing knowledge (e.g. when people try to use symbolic references instead of a hash or something equally useful).

In other cases it can point to lack of orthagonality, or possibly sub-optimal choice of names (would life be easier if length was called strlength or something similar?).

The fact that something is often asked about or requested may well be a clue (not proof :-) that there is a problem that needs to be addressed.

   There is no elsunless though. This is generally
   construed as a feature.

(the grain of salt included with this post is free of charge ;)

unless (!not_disabled('dont_block_visitor'))
{
      $confusion++;
}
[download]

$confusion-- unless !(not_disabled('dont_block_visitor') == 0);
$confusion++;
[download]

SCNR. :^)

Makeshifts last the longest.

It's not very elegant, but irregardless...

I couldn't fail to disagree with you less.