archives

A software engineering problem: how would functional programming solve it?

Here is a simple software engineering problem that I have encountered the last few days. It's not something dramatic, but one that has made me stop development in search of elegant solutions. I am posting this here because I would like to see how functional programming languages would solve this problem.

Here is the problem: I am writing a GUI toolkit that reuses the Win32 API wrapped up in a set of C++ classes (the reason is that 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)). As you may know, Win32 is not object-oriented, nor does it have a well thought out/consistent interface. For example, although the menu bar is a screen object, it is not a window: all there is is a bunch of functions for creating a menu, redrawing it, adding menu items etc. But I want to have menus and other non-window Win32 items as widgets in the toolkit, for consistency reasons.

The problem lies in the organization of classes. I have 4 types of widgets:

  1. widgets with no children and no window: for example, menu items
  2. widgets with no children and window: for example, buttons
  3. widgets with children and no window: for example, menus (which have menu items as children)
  4. widgets with children and window: for example, forms

The object-oriented design solutions would be:

  1. make non-window classes unrelated to widgets; something I don't desire as it is a non-consistent solution (after all, a menu IS a widget)
  2. make a generic Widget class that has children and all window properties and ignore those properties for non-window widgets; a nasty solution.
  3. have 5 separate classes: Component, Container (extends Component), Window (extends Component), WindowedComponent (extends Component, Window), WindowedContainer (extends Container, Window), using multiple virtual inheritance or aggregation. I also don't like this solution because of namespace pollution and because it will be seen as complex by the library's users.
  4. have 3 separate classes: Component, Container (extends Component), and template class Window that can be parameterized by the type of superclass (Container or Component). I also don't like this solution, because a) templates are slow in compilation, b) bloat the size of code, c) all code has to be in the header file.

So what I am asking is how functional programming languages solve an issue like the above, which is an issue of code organization/clarity/reuse/taxonomy. I can't seem to find a good object-oriented solution to the problem, nor any of my colleagues/friends can. So I am asking if other programming paradigms have a better solution for this problem.

[Fun, crass] The Daily WTF

If LtU is the zenith of PL discussion, the nadir might be The Daily WTF (where Whiskey Tango Foxtrot decodes from the phonetic alphabet to a vulgar interrogative).
If you would find refreshment in a "Bevis and Butthead to Code" kind of website, it's good for an occasional belly-laugh.

Happy Birthday, dear Lambda

Believe it or not, Lambda the Ultimate is five years old! Wow.

If someone would have told me five years ago that LtU will be around that long, I'd call him crazy. I still remember trying to recruit new members and trying to spread the word. Today? The number of members increases daily, whether I like it or not...

It's gratifying to see that many of the original members are still active, and that many members have their own specific roles in our virtual community. It's great to see people's interests and voice evolve over time, as well as to welcome guests and more occasional visitors.

Since moving to the new site (thanks Anton!) the membership and readership have increased dramatically. A rapid increase of this kind can undermine the norms and culture of a community, but I think we are doing fine, thanks mainly to the tone set by the LtU regulars. From time to time we may slip and the tone gets a little harsh, but what can you expect when static typing is being discussed? Overall, I think we are handling the growth remarkably well, and the new members make the dicussion more interesting and diverse.

The discussion group has become much more active than it was in the past, due to the increased readership. This is a good thing, of course, but I hope the blog can keep up. Being extremely busy prevents me to contribute new stories as often as I want, but I was glad to see how many volunteered to become editors. Now all they have to do is start posting more often..

Thanks again, guys. LtU keeps surprising and informing me, and frankly, what more can you ask for?