UR::DeletedRef(3pm)

💖 UR::DeletedRef — bestie, it's the ghost of an object that got deleted 💖

okay so real talk: this is UR::DeletedRef, a lil module from the User Contributed Perl Documentation collection, and it represents an instance of a no-longer-existent object. yes. an object that is gone. deceased. deleted. unalived, if you will. 🪦✨

---

✨ SYNOPSIS ✨

my $obj = Some::Class->get(123);

$obj->delete;
print ref($obj),"\n";  # prints 'UR::DeletedRef'
$obj->some_method();   # generates an exception through Carp::confess

$obj->resurrect;
print ref($obj),"\n";  # prints 'Some::Class'

like, watch the glow-up happen in real time. you grab your object with get(123), you call delete on it, and boom — ref($obj) now says 'UR::DeletedRef'. try to call $obj->some_method() and it will throw hands — an exception, via Carp::confess. then $obj->resurrect and suddenly ref($obj) is back to 'Some::Class'. the comeback era. 👑

---

🌸 DESCRIPTION 🌸

so here's the tea, bestie. object instances become UR::DeletedRefs when some part of the application calls delete() or unload() on them — meaning they no longer exist in that Context. the extant object reference gets turned into a UR::DeletedRef, and the whole point of that is: if that same reference gets used in any capacity later in the program, it will generate an exception through its AUTOLOAD. it's a safety net, fr fr. it prevents you from using a dead object by mistake. 🫶

---

💅 not to be confused with Ghost objects, no cap

UR::DeletedRef instances are different than Ghost objects. let me break it down:

• when a UR-based object is deleted through delete(), a new Ghost object reference is created from the data in the old object
• and the old object reference is re-blessed as a UR::DeletedRef
• any variables still referencing the original object now hold a reference to this UR::DeletedRef
• the Ghost object can be retrieved by issuing a get() against the Ghost class

so like… the Ghost is the data's afterlife, and the UR::DeletedRef is the cursed lil pointer that used to be your object. two completely different vibes. 🦋

---

🌈 also they come from transactions too

objects unloaded from the Context using unload(), or indirectly by rolling-back a transaction which triggers unload of objects loaded during the transaction, are also turned into UR::DeletedRefs. so it's not always you doing it on purpose. sometimes the transaction said "no <3" and took everything with it. 😭

---

🎀 will you ever actually meet one?

ngl, you aren't likely to encounter UR::DeletedRefs in normal use. what usually happens is this: an object gets deleted with delete() (or unload()), the lexical variable pointing to the DeletedRef will soon go out of scope, and the DeletedRef will then be garbage-colelcted. yes that spelling is in the original. we keep it. it's iconic. 💀✨

---

🔥 SEE ALSO 🔥

• UR::Object — the whole reason any of this exists
• UR::Object::Ghost — the data's haunted afterlife
• UR::Context — the place where objects live and, unfortunately, die

---

lowkey the whole module is just a "do not touch, this object is DEAD" sticker with main character energy. treat it with respect and it'll never yell at you through Carp::confess. 🙈

---

okay that's the whole page bestie, periodt 💖 this was UR::DeletedRef(3pm) from the User Contributed Perl Documentation, running on perl v5.32.1, dated 2022-01-17. go forth and never use a deleted reference again. slay. 🧚‍♀️💜