> On 13 Sep 2018, at 20:47, ToddAndMargo <toddandma...@zoho.com> wrote:
> On 09/12/2018 10:09 AM, Larry Wall wrote:
>> Basically, ignore any advice to treat Nil as a normal value, because
>> it really is intended to represent the *absence* of a value as much as
>> possible. It's a bit like the way solid-state electronics treats "holes"
>> as if they were real particles, and gets away with it much of the time.
>> But not all the time, because the hole isn't real; it's the collective
>> behavior of everything around a thing that's missing.
>> So while you can test explicitly for Nil if you try hard enough, it's
>> better not to try at all, because lots of places internally are using
>> that Nil to select some kind of default behavior that might or might
>> not look like Nil afterwards.
>> It was probably a mistake to put Nil into the type hierarchy underneath
>> the Any type in the first place. It's more of a concept type like
>> Junction, so probably belongs outside of Any, which sits the top of the
>> "normal" object hierarchy.
>> These types are deeply magical. Whenever you find yourself trying to
>> use Nil or Junction as a normal value, you have to ask yourself whether
>> you're just Mickey Mouse falling into the Sorcerer's Apprentice trap.
>> Unless you're a wizard, with Nil and Junction it's better to cargo cult
>> a few common usages and stay the heck away the rest of the time.
>> Larry
>
> Hi Larry,
>
> Beautiful description! Almost magical! :-)
>
> I will stick with .defined that you suggested in another
> thread.
Another way to deal with Nil is to use “with”, especially if you don’t need to
do anything if the value is Nil:
with “foo”.index(“o”) -> $index {
say “Found at index $index”;
}
Documentation:
https://docs.perl6.org/language/control#index-entry-control_flow_with_orwith_without-with%2C_orwith%2C_without
