When in doubt, it is usually better to [prefer composition over inheritance][1]. Still, that is just a heuristic, not a law, and asking if this heuristic applies to your specific case is definitely justified.

Here is a simple argument why I think you should prefer composition in this case: if you want to keep your design open to make `Drawable` a base class of certain more specific "drawables" **inside your library** (like 2D or 3D drawables, or OpenGL vs. DirectX drawables, or some other kind of *technical* classification), use composition. Such a technical inheritance hierarchy will not interact well when mixing it with a domain specific inheritance hierarchy outside your library, where `ProgramObject` may be the base class of certain domain specific class (like a player character, or a vehicle, or some kind of other object). 

This [article here][2] calls these aspects different **dimensions**:

> When you have a situation where either composition or inheritance will
> work, consider splitting the design discussion in two:
> 
>    - The representation/implementation of your domain concepts is one dimension
>    - The semantics of your domain concepts and their relationship to one another is a second dimension
> 
> In general, inheriting within one of these dimensions is fine. The
> problem becomes when we forget to separate the two dimensions, and
> start inheriting across inter-dimensional boundaries.

And this is exactly what would happen when you start to inherit a `ProgramObject` from a `Drawable`: you will mix up the "drawing" dimension with other domain concepts, and that is often a way to desaster.

  [1]: https://softwareengineering.stackexchange.com/questions/134097/why-should-i-prefer-composition-over-inheritance
  [2]: https://www.thoughtworks.com/insights/blog/composition-vs-inheritance-how-choose