http://qs321.pair.com?node_id=11110557

Hi

I started to write a test script for "Boolean Operators" with and w/o "Short-Circuit" in Perl.

And quickly found me needing to define and test "Truthiness" in Perl.

(Wait ... "0 but true" is false? Remembered it differently ;-)

And now I find myself obliged to also define "Contexts", because an empty list is also false.

And "Data Types", because internally it's more difficult, than just Scalar, Array and Hash.

It's a lot of work, but in the end it could help in many corners when done correctly:

Properly done means that it needs to be axiomatic, i.e. higher level tests need to only use features proven in lower levels.

Like so often, after a first success I find myself a bit stuck in the big picture.

I'll throw in my first approach as is for meditation.

There is a lot to be criticized, but my normal perfectionism is too risky and might lead to a never release cycle.

Thoughts?

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

Replies are listed 'Best First'.
Re: Defining, Testing and Documenting Perl?
by Tux (Abbot) on Dec 23, 2019 at 20:37 UTC

    /me mumbles .oO( ties and overloads )


    Enjoy, Have FUN! H.Merijn

      Fun fact: the Moose "Bool" datatype will accept overloaded objects, but only if they stringify to "", "0", "1" or undef. It doesn't care what they boolify to!

      Other fun fact: the Mouse "Bool" datatype will accept overloaded objects, but only if they boolify to a false value.

       

      This is why Types::Standard 1.004 abandoned trying to be compatible with Moose and Mouse's definitions of "Bool" and instead just accepts "", "0", "1" and undef, but offers a coercion from other values.

      > mumbles .oO( ties and overloads )

      what's your point?

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

        I believe a tied hash can override how it behaves in scalar context, so that an empty hash can return true and a non-empty hash can return false.

        An overloaded object can do various tricky things with regards to how it behaves as a boolean. For example, it could die.

        if ($x || $y) { say "Something was true. What was it?"; say '$x' if $x; say '$y' if $y; } else { say "Neither was true."; }

        It is possible for this to print "Something was true?" but not tell you what was true. This is because $x or $y could be an overloaded object returning true or false at random each time they are checked.

Re: Defining, Testing and Documenting Perl?
by Anonymous Monk on Dec 24, 2019 at 20:19 UTC
    Sorry to say that not one single programming language that has "stood the tests of time" – including, by the way, JavaScript – is immune to this. Programming languages are tools of our trade which usually are developed over many decades. Shit happens – and always will. "Engineer accordingly."
      No idea what you are talking about.

      > Shit ...

      Now I smell!

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

      A reply falls below the community's threshold of quality. You may see it by logging in.