DynamicObject::clone question

General JUCE discussion
1

Is there a reason why:

class DynamicObject
{
    virtual std::unique_ptr<DynamicObject> clone() const;
};

Returns a unique_ptr and not a DynamicObject::Ptr ?

2

Looks like there was an entry in the breaking changes for this

Change

DynamicObject::clone now returns unique_ptr instead of
ReferenceCountedObjectPtr.

Possible Issues

Overrides of this function using the old signature will fail to compile.
The result of this function may need to be manually converted to a
ReferenceCountedObjectPtr.

Workaround

Update overrides to use the new signature.
If necessary, manually construct a ReferenceCountedObjectPtr at call sites.

Rationale

It’s easy to safely upgrade a unique_ptr to a shared/refcounted pointer.
However, it’s not so easy to convert safely in the opposite direction.
Generally, returning unique_ptrs rather than refcounted pointers leads to more
flexible APIs.

3

Interesting, feel kind of weird to transport an intrusive reference counted object in a unique ptr…

4

To avoid potential mistakes i added this constructor:

var (std::unique_ptr<DynamicObject> object);

I found external code more or less like this, which exploded down the line.

var myVar (obj->clone().get());
// oops, someone forgot we had to release ownership,
// because `var` can only be constructed by `var(DynamicObject*)`
// which takes ownership. This would have changed if `var` 
// could only take a `var(DynamicObject::Ptr)` much like how you
// would design an API with unique_ptr and shared_ptr which i thought
// about doing but it was a more bigger breaking change
// but :man_shrugging: