Null object: Difference between revisions
m
Fix Perl 6 -> Raku in comments
(add task to ARM64 assembly Raspberry Pi) |
Thundergnat (talk | contribs) m (Fix Perl 6 -> Raku in comments) |
||
Line 1,651:
{{trans|Haskell}} (as it were...)
In
If you try to put <tt>Nil</tt> into a container, you don't end up with a container that has <tt>Nil</tt> in it. Instead the container reverts to an uninitialized state that is consistent with the declared type. Hence,
All type objects derive from <tt>Mu</tt>, the most-undefined type
object, and the object most like "null" in many languages. All other object types derive from <tt>Mu</tt>,
so it is like <tt>Object</tt> in other languages as well, except <tt>Mu</tt> also encompasses various objects that are not discrete, such as junctions. So
Mostly the user doesn't have to think about it. All object containers behave like "Maybe" types in Haskell terms; they may either hold a valid value or a "nothing" of an appropriate type.
Line 1,686:
$str = 42; # (fails)</lang>
But in the
for a way "to see if an object is equivalent to the null object."
The whole point of such a non-object object is that it doesn't exist,
and can't participate in computations. If you think you mean the
null object in
that is uninstantiated, and hence undefined. One of those is your "null object",
except there are many of them, so you can't just check for equivalence. Use the <tt>defined</tt> predicate (or match on a subclass of your type that forces recognition of abstraction or definedness).
undefined carriers of type, are also carriers of the <i>reason</i>
for the value's undefinedness. We tend view them as lazily thrown
| |||