Usually an abstract class would be used instead of +Entity, like +contact and then have +Customer, +Supplier, +CustomerSupport, +ExecutiveOfficer and so on inherit from this more general abstraction. Switching class at runtime is trivial in picolisp, and they could also have abstract parents like +contactavailabletoall, +contactavailableonlytosome or something else entirely.
Typically 'email and 'type in '+Emails would have some index prefix class too, to make them independently indexed and available to search algorithms, not just reachable through the +Contact objects.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for sharing, an interesting read.
In picolisp it would be expressed somewhat differently, perhaps similar to this:
(class +Contact +Entity)
(rel account_id (+Ref +Number))
(rel birthday (+Ref +Date))
(rel company (+Sn +IdxFold +String))
(rel emails (+List +Joint) contacts (+Emails))
(class +Emails +Entity)
(rel email (+String))
(rel type (+String))
(rel contacts (+List +Joint) emails (+Contact))
Usually an abstract class would be used instead of +Entity, like +contact and then have +Customer, +Supplier, +CustomerSupport, +ExecutiveOfficer and so on inherit from this more general abstraction. Switching class at runtime is trivial in picolisp, and they could also have abstract parents like +contactavailabletoall, +contactavailableonlytosome or something else entirely.
Typically 'email and 'type in '+Emails would have some index prefix class too, to make them independently indexed and available to search algorithms, not just reachable through the +Contact objects.