Interestingly, the opaque shortcut used to be
$class.bless(undef, *%_);
But I made it 0 instead merely because it's shorter. That does, however,
free up "undef" as a way of asking for an explicitly undefined but
blessed value.
: There are potentially two flavors of undef:
:
: undef
:
: undef but class = C
There are potentially many flavors of undef already. I've already said
that many undef flavors contain an unthrown exception stating why the
value in question is undefined, such that if you try to use the value
as defined, you can throw an intelligent exception that will point the
user back to the real problem.
That is one of the real innovations in Perl 6, as opposed to the borrowings.
: Given that the foo and bar methods are declared to return C, should the
: 'return undef' code emit a 'pure' undef, or a undef-of-type-C?
Don't know the answer to that one. One possible answer with a certain
amount of appeal is that it is completely illegal to return a bare undef.
It either has to be an unthrown exception, or a proto-object.
: And if so, should it be legal to have an undef invocant? A typed-undef
: invocant?
Depends on what it's pretending not to be, I suspect.
: This sort of wanders towards the question: Is undef a value, or a
: meta-value? That is, can a UDT rely on scalar undef as part of its range (a
: la NaN/Inf in the numbers space) or must undef be considered part of the
: Perl domain, "you're not a Thingy yet."
I'd say the concept of defined/undefined as a constraint depends entirely
on whether the object in question returns true or false to .defined(),
regardless of its other characteristics. Perl is otherwise agnostic to
its thinginess, at least until you ask it to care.
: (The mapping of undef <-> SQL's NULL comes to mind.)
Hmm, yes, that might fall out rather neatly, as long as it's clear to
the reader when you mean NULL rather than undef. It's almost a funny
kind of junction.
Larry
