* David Abrahams <dave@boost-consulting.com> [2004-12-30 14:53]:
Reece Dunn wrote:
David Abrahams wrote:
Yeah, geez. Single-rooted hierarchies of diverse functionality with a root class called "object" were discredited long ago, weren't they?
I am not suggesting a single-rooted heirarchy for *all* the classes as that would be stupid. MFC does it to support their own version of RTTI, memory leak tracking, etc. Java does it because it doesn't have templates. .NET has it because it treats every object as a COM object.
Python does it too. It's not neccessarily wrong for other languages; just C++.
The heirarchy above is for a UI object, where a UI object has moving/positioning and event handling integral to it. Consider:
How do you intend on writing *UI objects* - frames, widgets, layout managers, etc. - that can interact with each other, be moved and process events correctly without sharing a common *ui::object* base? Here, I was using the namespace as part of the name to denote the role that the class plays, not that it is a monolithic uberclass.
A layout manager that can be moved?? Maybe you have something else in mind, but I understand a layout manager to be a supplier of logic with no graphical representation.
David, That's the distinction I'm trying to make between renderers and layouts. Reece is discussion a form/frame renderer. The strategy there is to use a tree of nested boxes. Example: Yuumight have a splitter layout containing a NS/EW layout, containing a grid layout (not a grid renderer, but an object that arranges more objects in a fixed grid), in the grid layout you have a list box, it has list items, etc. When the splitter is moved, it changes shape and calls the ES/EW layout, which changes shape and calls the grid layout, which changes shape and calls the list box, which changes shape and calls the list items, which change shape and call... Java AWT, Swing, Delphi all use the term Layout to describe these boxes of boxes. A grid layout is an row/column layout of from controls, it doesn't provied for resizing, sorting, ranges. A flow layout lays out controls left to right, but it doesn't layout text, paragraphs, columns, etc. In this strategy, you are choosing to use memory to model each axis-aligned bounding box as an actual object. This is why I call it the *form* rendering strategy, and draw distinctions between the *grid*, *document*, and *canvas* rendering strategies. That is why I'm talking about rendering, to make the distiction between this simple, but inscalable strategy, and other, more scaleable rendering strategies. There is a place for the *form* strategy, but I don't think it is a foundation for all rendering. Especially not in a generic programming language. -- Alan Gutierrez