You'll probably want to redefine the C function pointer PL_ppaddr[OP_DEFINED] to handle your objects specially. See chromatic's "Did You Know This Worked?"

You could concoct something with tie, where a tied variable's object instance possesses additional attributes besides its primary value (which may indeed be undef).

sub FETCH { return undef } works for defined($undef) and (tied $undef)->{exists} can store out of band properties.

I couldn't get this to round-trip with YAML, I guess special serialization code would be required, either using YAML::Node or some caller() checking kludge in FETCH.

Then deserializing would need another hack... nevermind

Brad

Why? This has the smell of an XY Problem.

I asked because I couldn't think if a way to do it and it seems generally useful to be able to use interesting values of undef (eg. Perl6 is to support this for exceptions and potentially other things).

I can solve the problem at hand by other means, so my question is not seeking a specific solution but a general technique, and knowledge about what is possible in Perl 5.

Since you are curious about the context, I have an application which uses Storable for persistence and undef is used to represent "no answer". This works nicely for the core engine. I'm now working on a tool chain to convert a this data into various presentation formats, a few of which would like to distinguish between existant/nonexistant undefs and present them differently (the distinction being "no answer"/"no answer, never saw the question"). The distinction is more in the minds of the users than anywhere else, most of the utilities will not make this distinction and shouldn't be troubled by it. My current solution is to maintain the flags in a separate structure in parallel to the main data stream.

My original question mentioned YAML because the data stream pipeline uses IO::YAML pass data beween utilities.

If you have other suggestions, they're welcome,

Brad

Would it be appropriate to use an object to represent either the answer, the question, or the question and answer? If magic is to be invoked in any case, better to invoke "standard" magic than to invent a tricky sort of magic such as giving meaning to something who's only meaning is to say "you can know nothing about me because I don't exist".

---

DWIM is Perl's answer to Gödel

I've often been told that it's a bad practice to use the lack of data to mean something. An undef means we have no data. If you want it to mean something else, as you do here, I think it's a lot better to make some data that explicitly means "no answer" as GrandFather suggested. It's also probably wise to steer clear of the kind of trickery that would be required to do what you asked for originally, since it's likely to be a brittle solution.

You might find Juerd's undef isn't presentation from YAPC::EU of interest.