Question

I’ve been developing a GUI library for Windows (as a personal side project, no aspirations of usefulness). For my main window class, I’ve set up a hierarchy of option classes (using the Named Parameter Idiom), because some options are shared and others are specific to particular types of windows (like dialogs).

The way the Named Parameter Idiom works, the functions of the parameter class have to return the object they’re called on. The problem is that, in the hierarchy, each one has to be a different class — the createWindowOpts class for standard windows, the createDialogOpts class for dialogs, and the like. I’ve dealt with that by making all the option classes templates. Here’s an example:

template <class T> class _sharedWindowOpts: public detail::_baseCreateWindowOpts {     public: ///////////////////////////////////////////////////////////////     // No required parameters in this case.     _sharedWindowOpts() { };      typedef T optType;      // Commonly used options     optType& at(int x, int y) { mX=x; mY=y; return static_cast<optType&>(*this); }; // Where to put the upper-left corner of the window; if not specified, the system sets it to a default position     optType& at(int x, int y, int width, int height) { mX=x; mY=y; mWidth=width; mHeight=height; return static_cast<optType&>(*this); }; // Sets the position and size of the window in a single call     optType& background(HBRUSH b) { mBackground=b; return static_cast<optType&>(*this); }; // Sets the default background to this brush     optType& background(INT_PTR b) { mBackground=HBRUSH(b+1); return static_cast<optType&>(*this); }; // Sets the default background to one of the COLOR_* colors; defaults to COLOR_WINDOW     optType& cursor(HCURSOR c) { mCursor=c; return static_cast<optType&>(*this); }; // Sets the default mouse cursor for this window; defaults to the standard arrow     optType& hidden() { mStyle&=~WS_VISIBLE; return static_cast<optType&>(*this); }; // Windows are visible by default     optType& icon(HICON iconLarge, HICON iconSmall=0) { mIcon=iconLarge; mSmallIcon=iconSmall; return static_cast<optType&>(*this); }; // Specifies the icon, and optionally a small icon     // ...Many others removed... };  template <class T> class _createWindowOpts: public _sharedWindowOpts<T> {     public: ///////////////////////////////////////////////////////////////     _createWindowOpts() { };      // These can't be used with child windows, or aren't needed     optType& menu(HMENU m) { mMenuOrId=m; return static_cast<optType&>(*this); }; // Gives the window a menu     optType& owner(HWND hwnd) { mParentOrOwner=hwnd; return static_cast<optType&>(*this); }; // Sets the optional parent/owner };  class createWindowOpts: public _createWindowOpts<createWindowOpts> {     public: ///////////////////////////////////////////////////////////////     createWindowOpts() { }; }; 

It works, but as you can see, it requires a noticeable amount of extra work: a type-cast on the return type for each function, extra template classes, etcetera.

My question is, is there an easier way to implement the Named Parameter Idiom in this case, one that doesn’t require all the extra stuff?

Answer 1

Maybe not what you want to hear, but I for one think it’s ok to have lots of ugly type-casts and template parameters in library-code that’s (more or less) hidden from the client as long as it is safe and makes the life of the client a lot easier. The beauty in library code is not in the code itself, but in the code it enables the clients to write. Take STL for example.

I’ve also developed a small GUI-library as a personal project with basically the same aspirations as you and some of the code gets pretty ugly in it, but in the end it allows me to write beautiful client code (at least in my (possibly perverted) eyes) and that’s what counts IMHO.