in reply to Re: Mr. Ternary is greater than Mrs. If Else
in thread Mr. Ternary is greater than Mrs. If Else

well, overall its all about readability problems with Mr. Ternary...

to easily remember the structure of Mr. Ternary a multi-decision structuring as follows:

<expression> ? eval { <statement>; <statement>; <statement>; <expression> ? eval { <statement>; <statement>; <statement>; } : eval { <statement>; <statement>; <statement>; }; } : eval { <statement>; <statement>; <statement>; <expression> ? eval { <statement>; <statement>; <statement>; } : eval { <statement>; <statement>; <statement>; }; };

NOTE: (eval or \& or do) well also work

literally, Mr. Ternary is more on simple symbols that gives you a more concentration on expressions and statements without being bothered with words like if, elsif, and else.

i don't think so that other languages could make Mr. Ternary more functional (making Mr. Ternary hold multiple-statements) than Perl could do. what do you think?

Replies are listed 'Best First'.
Re^3: Mr. Ternary is greater than Mrs. If Else
by shmem (Chancellor) on May 20, 2007 at 08:54 UTC
    This looks quite orderly, since the only words you are using here are 'eval', 'statement' and 'expression'. If you fill that with 'real code', the picture will get different, and the tiny ':' will get hard to spot at a glance.

    In contrast, 'if-elsif-else' statements stand out and are thus better readable on larger constructs.

    As for \& {}, that's an abuse of the coderef constructor and it will clutter up your symbol table.
    <expression> ? eval { <statement>; <statement>; <statement>; <expression> ? eval { <statement>; <statement>; <statement>; } : eval { <statement>; <statement>; <statement>; }; } : eval { <statement>; <statement>; <statement>; <expression> ? eval { <statement>; <statement>; <statement>; } : eval { <statement>; <statement>; <statement>; }; };
    if (<expression>) { <statement>; <statement>; <statement>; if (<expression>) { <statement>; <statement>; <statement>; } else { <statement>; <statement>; <statement>; } } else { <statement>; <statement>; <statement>; if (<expression>) { <statement>; <statement>; <statement>; } else { <statement>; <statement>; <statement>; } }

    What do you do with your large ?: construct if you have by chance to insert a third condition (a.k.a elsif) statement? Which of both columns is better readable? Can you tell at a glance if there's a semicolon missing (or one that causes a syntax error) on a line in the left column?

    --shmem

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                  /\_¯/(q    /
    ----------------------------  \__(m.====·.(_("always off the crowd"))."·
    ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

      okey... you got the power. well, i got no things in mind yet to mind storm with Mr. Ternary over Mrs. If Else. anyway my delimma was already solved. thanks guys. it was appreciated... i will come back to this topic very soon, if ever i find a good try over Mrs. If Else in Perl.

      now, the good news is Mr. Tarnary operator can be used in multi-statements unlike to what i usually hear about it (that it can only be used in single statement only).

        now, the good news is Mr. Tarnary operator can be used in multi-statements unlike to what i usually hear about it (that it can only be used in single statement only).

        Nope: the arguments to ?: are expressions, period. But then Perl also has operators/functions/constructs that let you "interpolate" a whole block of code containing multiple statements into a single expression. Thus you have two different tools that you can use synergetically together: this is nothing new - just build something complex out of simple pieces.

        Update: (some philosophy) I've tried, along with others, to explain you that if, else, etc. on the one hand and ?: on the other one are different things with different purposes, although also with some overlapping. Now I'll try with an analogy: suppose you have both a pickup and a scooter available. Now, if you have a huge load to bring from some place to another place, you will probably use the former, but if it's a tiny package, the latter. Granted: nobody prohibits to you to also use the pickup to transport the tiny package nor to invent some smart binding that will allow you to put the huge load on the scooter. That is exactly what you're doing. There are languages in which you only have either the pickup or the scooter: in those cases you have to do it those ways. But Perl lets you decide: it lets you decide to pick up the best suited tool for any given job - and also the not best suited one, if you really insist to. That's part of its TMTOWTDIness.

Re^3: Mr. Ternary is greater than Mrs. If Else
by blazar (Canon) on May 20, 2007 at 12:54 UTC
    literally, Mr. Ternary is more on simple symbols that gives you a more concentration on expressions and statements without being bothered with words like if, elsif, and else.

    Indeed: if, else, elsif are flow control constructs. ?: is an operator. Now, it happens, thanks to short circuiting and the availability of constructs that take a block and execute it, that the latter can be used in a semantically equivalent manner to the former. Yet, as has been repeatedly explained to you in this thread, they serve different purposes: there are superimpositions and there may be some situation in which the choice is not obvious. But this is generally not the case.

    i don't think so that other languages could make Mr. Ternary more functional (making Mr. Ternary hold multiple-statements) than Perl could do. what do you think?

    I don't understand your question, but I'll make some guess and try to answer anyway: in some functional languages, the regular branching control structures behave much like (C and) Perl's ?: in that they return a value - exactly because they're functional. But seriously, your insisting on this issue makes me think that you're simply fond of the extreme conciseness you get out of it. OTOH several different monks already explained to you the reason why we generally do not strive for extreme conciseness: Perl has already a wrongly deserved bad name for being mostly line-noise, in some circles and speaking of other languages if I were to write programs that look like brainfuck I would... program in brainfuck! But then joy the world: Perl 6 will have a grammar modifiable at runtime, so you will be free to happily brainfuck it!