Lambda the Ultimate

... there is no GUI library that completely hides Win32 will reusing it - existing libraries either follow Win32 logic (ala WxWidgets) or provide their own implementation (ala Qt/Swing).

Tk hides the details of Win32 programming model, but uses native widgets on both Windows and Mac. If you grab the Tile extension it will also pick up Win XP themes. It's also a darn sight easier to use than Qt, Swing or WxWidgets. Is there any specific reason why you wouldn't want to use it?

Other than that, pretty much every FP language will have some GUI toolkit, so I'd suggest having a look at what is out there. You also might want to look at Haskell's type-classes.

In the MSDN library under WIN32 API there is a description of how to use the basic C/SDK window system. (the mother of all window systems?) It seem very straight forward and easy to understand compared to MFC. The only problem is that you have to type in about 100 lines of ugly C code, or you can cut and paste the GENERIC.C sample and start adding your own call back functions, etc. I believe that there are respectable people who still use this system although I don’t know who they are.

Tk does not support the Model-View-Controller paradigm, does it? And most FP languages use either Gtk, or wxWidgets, or some other X-Window System-only toolkit, which does not directly show me how an FP language would solve the problem I have. WxWidgets does not hide Win32 details (for example, it uses message maps instead of overloading), and Gtk does not honour the constraints I have (for example, Gtk Buttons and Gtk MenuItems are containers).

You seem to be conflating two things - the model you want to present to the user and the model used for the implementation.

The issue with this is that the original architecture did not have a nice OO structure with its components well-related by a sensible inheritance structure.

You cannot build a *transparent* object model of what is an essentially ad-hoc component-based architecture without exposing the ad-hoc component-based nature of the underlying architecture.

As such, if you want to provide a nice OO structure containing inheritance for this collection of components, you'll need to use the underlying system only as an artifact of implementation, plastering over the "transparent model" to provide your own abstractions.

This will require some cruft in the implementation regardless of how you model the object hierarchy.

If I were designing a model to expose to the user, I would have a base Component class and a subclass of that called CompoundComponent which added a collection of sub-components. I'd then have a Window class (probably inheriting from CompoundComponent, because it would have it's own set of child components - e.g., scroll bar widgets, title bars, etc.) with a secondary collection of Components called "contents" that holds what's contained in the window. I'd then place Menus, Buttons, Forms, etc., in the external facing object model in a way that makes sense in this model. So what if a Button is a Window in Win32? It doesn't need to be one for 99% of your users, so don't expose that use fo the component. Do the same analysis for the other primitive Win32 components. Build a sane object model for the user and leave the Win32 cruft where it belongs - the implementation world.

Again, you cannot build a *transparent* object model of what is an essentially ad-hoc component-based architecture without exposing the ad-hoc component-based nature of the underlying architecture.

(If you want an overview of the main message of this long post, read fadrian's post which was posted while I was writing the following mini-essay.)

First, I'll note that this is not actually a programming language question, and despite appearances, it's not even a question about comparison between paradigms — it's really about How to Design Programs, a subject for which many of the principles transcend any specific paradigm.

It sounds as though the best approach here will be somewhere between #3 and #4, but that the problems with such approaches has more to do with limitations of C++ than the appropriateness of the conceptual designs. For example, all of the problems mentioned with approach #4 would be non-issues in a language with a good polymorphic type system (e.g. ML, OCaml, Haskell). In addition, some of the complexity in #3 comes from the need to use multiple inheritance merely to provide common interfaces across a set of classes.

Unfortunately, C++ fails to explicitly separate interface inheritance from implementation inheritance, which means that it's up to the programmer to organize code in a way that hides implementation details, as opposed to relying on the language to do so. This means that a price is paid in terms of implementation complexity, merely for hiding implementation details. (In C++, Real Programmers implement their own implementation hiding mechanisms, and some of the most famous books about C++ focus heavily on such techniques.)

Regardless of what language or paradigm you're using, you should start out by being careful to distinguish between the design of the interface to your library, and its implementation. In C++, it can be difficult to avoid confusing the two, and this often results in confused design. With proper separation, the problems of complexity and namespace pollution don't arise, because the interface will only provide what's actually needed by clients of the class to get the job done, and nothing more. This means every feature of the interface can be justified by saying "you need that to be able to...", not "we had to put that in because the implementation..."

So, the first task is to forget entirely about the implementation, and look at what makes sense for clients of these classes. Don't think about code reuse or the organization of the implementation, think only about interfaces. The interface should not contain anything which has to be explained in terms of the implementation — that's what leads to complexity and namespace pollution.

As part of this process, you should be careful to avoid allowing the bad design of Windows to contaminate your interface design. Factoring the design around an abstraction called a "Window", so that e.g. a Button ends up being some kind of Window, presupposes a great number of design choices related to what a Window is. If the goal is to require that users think in terms of Microsoft's abstractions, fine, but that's an external limitation on the design which constrains the possible solutions.

At the very least, in the design phase you will be better off treating a Window as an hidden implementation detail, so that if you do decide to expose some version of that abstraction to your users, you do so with a better understanding of its relationship to your design, which should be more clearly factored than that of Windows.

As another example here, the idea in #4 of having a Window class as a template parameterized by Container or Component seems wrong from the library user's perspective. How would you explain to a library user why such a design was chosen, without resorting to talking about implementation details that should be hidden? Of course, it's possible that you might use such a design internally in order to achieve code reuse, but if there's a reason to expose that detail to library users, it hasn't been made clear.

What needs to be examined are the operations that need to be performed on concrete objects such as buttons, menus, menu items, etc., and how best to factor those operations for users of the library, so that they can use common interfaces to access the different kinds of objects, where that makes sense. This is actually a standard OO design exercise, which seems to have been confused in the question by implementation details relating to C++ and Windows.

From the problem description given, it seems that a likely solution at the interface level might involve as few as three interfaces: in the language of approach #3, these would be some variation of Component, Container, and Window (bearing in mind that "Window" is an interface whose purpose hasn't yet clearly been defined). It seems likely that Container and Window would be subtypes of Component.

Once the interface design work has been done, the result should be a suitable interface for users of the library. The next task is figuring out how to express that interface design in the target language. Even in C++, expressing an interface design is not that difficult. If the result does end up with interfaces that cut across classes (as seems likely), it might very well make sense to use multiple virtual inheritance to implement that, but that should be expressed purely at the interface level, e.g. using multiple virtual inheritance from pure abstract classes (a.k.a. interfaces).

In Java, you'd use Java's explicit interface mechanism to implement something like this; in Haskell, you might use typeclasses; in OCaml, you might use structural subtyping. The functional languages also tend to have a number of other ways of expressing this sort of thing (e.g. functors, units), because of the flexibility of higher order functions and their ability to parameterize behavior.

The part where things will start to get messy in C++ is in implementation. That's nothing to do with object-orientation, it's purely to do with the limitations of C++. Having to suck up messy implementation details is part of the deal with the devil you make when using C++. (Like most deals with the devil, any perceived upside is purely illusory.)

Again in terms of the implementation described in approach #3, the widget implementations might map to interfaces as follows:

Note that although it might be useful to have implementation classes such as WindowedContainer or WindowedComponent to support reuse of code in the implementation of some widgets, that doesn't necessarily mean that these classes should be exposed to users of the library, except possibly to help them achieve code reuse in implementing new widgets of their own. In that case, it should be recognized and made clear that the purpose of such classes is reuse of implementation, and that they do not represent part of the client code interface to widgets.

Note further that if a class such as Form is implemented by inheriting from a WindowedContainer class, then ideally, that implementation inheritance should be hidden from users of the Form class. Strategies to do this sort of thing are standard fare in the C++ literature, see e.g. Coplien or Alexandrescu. If you choose to forgo such strategies, then you have to recognize that you're making an optimization choice which results in less clearly delineated boundaries between interface and implementation, which results in leakage of implementation concerns into the client's code. In C++, this has consequences related to header file dependencies and so on, so forgoing such encapsulation puts the usability of the resulting library very much at risk. You wouldn't need to worry about this sort of thing in a higher-level language.

I've provided some suggestions phrased in fairly OO-sounding terms. However, don't be misled into thinking that such solutions are unique to OO. Separating interface from implementation is a basic design strategy, which ironically, most OO languages do a particularly poor job of: they conflate interface and implementation at multiple levels, most damagingly in the inheritance mechanism.

If you really want to understand these issues, your best bet is to forget about OO, and look at the ways in which truly abstract interfaces can be created with higher-order functions — both "manually", as well as via related mechanisms such as functors (e.g. in ML) and units (in PLT Scheme; see here for a gentler introduction). Given familiarity with such systems, the shortcomings in OO languages in these areas become clear, and it is easier to avoid the traps which the design flaws in OO languages create.

The overriding point in all of this is that designs should first be done conceptually, and abstractions should be designed, well, abstractly. Once you've done that, the rest is just a matter of expressing the abstractions in your chosen language. The functional languages have an advantage here for many reasons — they're higher level, and more expressive both in terms of abstraction capabilities and their type systems; but even if it weren't for that, the mere fact that they don't have fundamental errors in the design of their core abstraction mechanisms is a huge benefit.

[Edit: another nice introduction to some of the issues I've touched on above can be found in Matthias Felleisen's Components and Types.]

Thanks a lot for the replies, they are really appreciated.

Since the specified problem states that you're building on top of the Win32 API, I really doubt that you're going to be able to avoid imperitive programming. My advice in this specific instance would be to use a language like Ocaml which supports both imperitive and OO programming, and do things the obvious way.

That being said, I think there's an interesting area of debate: how could/should you design a proper functional GUI library? I'm assuming that you'd have a fundamental imperitive monad to do the actual I/O, something of the form (in Ocaml's types):

val putpixel: x:int -> y:int -> color:int -> unit

I'm thinking of splitting the drawing of the various GUI widgets from handling their behavior. So take the scroll bar widget. There would be two "objects" associated with the scroll bar. One would be the function to draw the scroll bar in it's current position. The other object would be a listener- so when you clicked on the scroll bar to move it, the listener would change the current set of drawable objects- replacing the current scroll bar drawing function with a new scroll bar drawing function that draws the scroll bar in it's new place. Especially as the scroll bar listener object also changes other how other drawing functions, for example the drawing function of the text field associated with the scoll bar.