> -----Original Message----- > From: Larry Wall [mailto:[EMAIL PROTECTED] > > 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.
^^ This is pretty much the whole answer. Sweet! ^^ > > : 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. Sure, but "You haven't provided a value yet." doesn't seem very ... exceptional. > 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. I was hoping for "Perl will type-convert the undef for you". :-) > : 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. Sure -- the class of the object may object to the object being undef. (Sorry :-) But does Perl object to an undef object of the class of the object object? That is: $foo = (undef as Dog).collar(); > : 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.
