[bccdee]

> Every display object has a x y width and height for example.

Intuitively¹, I feel like this is something that should be separated out into a BoundingBox object. Every component that needs a bounding box satisfies a small `HasBoundingBox { getBoundingBox(self) -> BoundingBox }` interface. Maybe there's a larger `Resizeable` interface which (given a type that satisfies `HasBoundingBox`) specifies an additional `setBoundingBox(self, bb)` method.

You don't end up with a tidy hierarchy this way, but I'm not sure you'd end up with a tidy hierarchy using inheritance, either. I feel like this sort of UI work leads toward diamond inheritance, mixins, or decorators, all of which complicate inheritance hierarchy. Flat, compositional design pushes you toward smaller interfaces and more explicit implementations, and I like that. The verbosity can be kept in check with good design, and with bad design, the failure mode leans towards more verbosity instead of more complexity.

For more complicated features, composition & interfaces can make things more verbose, but honestly I like that. Inheritance's most powerful feature is open recursion (defined in the linked article), and I find open recursion to be implicit and thorny. If you need that level of power, I'd rather the corresponding structure be explicit, with builders and closures and such.

[1]: Not saying this is correct, but as someone who prefers composition to inheritance, this is what feels natural to me.

[lukan]

"You don't end up with a tidy hierarchy this way, but I'm not sure you'd end up with a tidy hierarchy using inheritance, either."

Well, I am sure, that all the graphic libaries I ever used, had this inheritance model. (The graphics libary I build, as well.)

The libaries I have seen, that used a different model, I did not really like and they were also rather exotic, than in wide use. But I am willing to take a look at better designed succesful inheritance free ones, to see how it can be done,.if you happen to know one ..

[bccdee]

None of the graphics libraries you've ever used were built with mixins, decorators, or multiple inheritance? I confess I never went too deep with GUI toolkit programming, but Swing, for instance, definitely uses decorators (e.g. JLayer).

Neither Go nor Rust have inheritance, so any graphic library implemented in those languages will be inheritance-free; ditto anything in a functional language, for the most part. In general, these tend to be very declarative toolkits, being post-React, but they should illustrate the point. For something more widely used in industry, I know Imgui is a popular immediate-mode library.

[amypetrik8]

I mean if you writing joe slop tax softare you can use whatever mixin decorator singleton factory performance be damned, slop doesn't need performance, in fact, is frowned upon in slop developers as too showy and flashy, puts people off.

Now if you're say writing a high performance game, rendering engine, then maybe you want to squeeze out another 10 frames per second (FPS) but not committing resources to the overhead of that mixin decorator singleton factory facade messenger design pattern and just have some concrete tight C or assembly loop at the beating heart of it all