# Proposed change to PersistentObject

**URL:** <https://discourse.kitware.com/t/proposed-change-to-persistentobject/245>\
**Category:** Design\
**Created:** [April 10, 2019, 10:10pm UTC](https://discourse.kitware.com/t/proposed-change-to-persistentobject/245 "2019-04-10T22:10:00Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![tj.corona](https://discourse.kitware.com/user_avatar/discourse.kitware.com/tj.corona/32/35_2.png) [@tj.corona](https://discourse.kitware.com/u/tj.corona)\
**Post date:** [April 11, 2019, 1:26pm UTC](https://discourse.kitware.com/t/proposed-change-to-persistentobject/245/4 "2019-04-11T13:26:49Z")

</div>

One option is to have `smtk::resource::PersistentObject` maintain its pure virtual methods to a `Links` instance as @dcthomp suggested, implement it in `Project` (as it is done for `ResourceLinks` and `ComponentLinks`) with another `smtk::common::Links` datastructure, and modify the `smtk::resource::Links` API to avoid the need for direct casts to children of `smtk::resource::PersistentObject`. I suspect it will not be long before someone will want to link some piece of information to a `Project` instance.

FWIW, if this seems like a fair bit of infrastructure change, it is because the original design was designed around `Resource`s and `Component`s; their common base class was added after the fact. The addition of a third, distinct entity and its need to interoperate with tools that were designed to handle the original use case is not a small change. I think the generalization of `smtk::resource::Links` to handle any subclass of `smtk::resource::PersistentObject` would result in a nice, extensible pattern that we could use to easily handle the _next_ persistent object.

---

_[View the full topic](https://discourse.kitware.com/t/proposed-change-to-persistentobject/245)._