C++Talk.NET

Thomas Hansen · Guest

NOW I got your attention...
;)

Sorry couldn't resist, but I AM serious, follow up and I'll try to
convince you too...

Regarding this post:
I had some posts earlier in this newsgroup about this particular
subject, but now I have refined my thoughts a bit and I have gotten to
test them in practice and I am becoming more and more convinced about
the usefulness of "Magic Enums"!

In the last 20 years or so we have been thought that in OO to use
Inheritance you MUST have one thing existing in order for a class to
be "inheritable" from another class:
"The IS A relationship" or the Liskov Substitution Principle!
The best example of why is when it is NOT present as in the
Rectangle/Square or Circle/Ellipsis problem...
By definition I agree totally with the Barbara Liskov but I have found
implementation semantics in C++ which will make the Liskov
Substitution Principle "obselete"...
Note that this does only work in C++ and not any other languages (at
least not languages which I know... ;)

Imagine you're having this class AspectSizable which can resize
Widgets, the class comes with several "generic" functions and some
"not so very generic functions"...

class AspectSizable
{
public:
// Implementation left undefined since it's of no importence
void setSize( unsigned posX, unsigned posY, unsigned sizeX, unsigned
sizeY );
void setWidth( unsigned newWidth );
/* etc... */

/* Now here comes the "not so generic functions" */
void maximize();
void minimize();
void restore();
};

The NICE thing about the above class is that it is ONE class for
everything that have to do with sizing of Widgets!
This is nice since they may share implementation and you know where to
find "everythign that has to do with sizing of Widgets"
Now the BAD thing about the above class is that not all Widgets which
can use the AspectSizable class comes with support for being
"restored()", "maximized()" or "minimized()"!
It doesn't make much sense in trying to "maximize()" a WidgetButton
for instance or a WidgetDropDownList...

Q:
So what do we do?

A:
Magic Enums!

Q:
How can we (compile time) inherit a class from only "parts" of the
AspectSizable class?

A:
By using Magic Enums!

Lets declare the WidgetDialog (which SHOULD have support for being
maximized...

class WidgetDialog
: public AspectSizable<WidgetDialog>
// Mark! AspectSizable is now a template class and
// it is "brought" the class inheriting from it in the
// template parameter
{
public:
enum canBeMaximized; // MAGIC ENUM!
/*... rest of class ...*/
};

then lets declare the WidgetButton (which should NOT have support for
being maximized...

class WidgetButton
: public AspectSizable<WidgetButton>
{
public:
// Here there is NO enum which is called canBeMaximized...
*/... rest of class ...*/
};

Now let's "rewrite" the AspectSizable (or parts of it)

template<class WidgetType>
class AspectSizable
{
public:
// I've only included impl. of this one function since
// it's the only relevant for the example
void maximize()
{
// Here we will get a compile time error if the
// WidgetType does not have
// a member called canBeMaximized!!
WidgetType::canBeMaximized;
/* ... implementation of maximize ...*/
}
};

According to the template specifications a member function to a
template class will NOT get compiled unless it is referenced,
basically meaning that we can inherit from AspectSizable in both
WidgetDialog and WidgetButton and as long as we don't explicitly call
"maximize()" it will never be compiled!
Now if you have an object of type WidgetDialog and you call the member
"maximize()" all is well, but if you have a WidgetButton and call
"maximize()" YOUR CODE WON'T COMPILE!!
Just what we wanted!

We have a compile time mechanism to ensure that our code (and
application) behaves correct!!
And off course it comes with ZERO runtime overhead!
(the optimizer of even "the worst" compiler will optimize away the
reference to the Magic Enum)

Q:
But what is the advantage?

A:
You get to use inheritance in a more "natural" way, you can stuff
functions together inside a class which you "feel" are the right
places to put them, thus making the code more intuitive...

After all at the end of the day a Square IS (yes really it IS) a
Rectangle!!
If you ask a mathematician, a child or basically anybody else then a
hardcore OOP developer they will tell you that a Square really IS a
Rectangle!
Everybody in the whole world can assume that a Square is a Rectangle
EXCEPT OO developers...

So you can design your classes in a more intuitive hierarchi since you
have compile time mechanisms to ensure that you don't "mezz up" and
tries to call "maximize()" on your WidgetDropDownList or "fly()" on
your Submarine...
;)

Rewrite your OO books, C++ to the rescue!

If you want to see a concrete implementation of the concept feel free
to look here:
http://cvs.sourceforge.net/viewcvs.py/smartwin/SmartWin/Aspects/AspectSizable.h?rev=1.11&view=markup
And look in the implementation of "restore()" (at the bottom of the
file) and you will see a dereference of the
"WidgetType::MaxiMiniRestorable;" which is only declared in the:
http://cvs.sourceforge.net/viewcvs.py/smartwin/SmartWin/Widgets/WidgetWindowBase.h?rev=1.6&view=markup
class... (which CAN be restored)
While widgetCheckBox (which can NOT be restored):
http://cvs.sourceforge.net/viewcvs.py/smartwin/SmartWin/Widgets/WidgetCheckBox.h?view=markup
does NOT declare the "enum MaxiMiniRestorable;"...

So I get to group things which I feel is natural to have together in
ONE class (AspectSizable) instead of having to temper with TWO
classes...

I think this is pretty awesome!!

PS!
If you think this looks like something you've seen before then I must
admit that Andrei Alexandrescu and Compile Time Assert was the
inspiration of the concept, but allthough Compile Time Assert is very
nifty it can not solve the problems that Magic Enums can solve...
The magic enums gives you the possibility of creating UDT union
classes...

In fact it would be possible (theoretically, I don't say it's
feasable) to take all your classes in your > 1MILL classes application
and merge every class together into ONE hugh template class and just
instantiate that one single class with different template parameters
(consisting of policy classes with lots of Magic Enums) without
loosing typesafety at all!!
(all though I would buy lots and lots of painkillers and neuroleptica
before doing that if I were you... Wink

)

Thomas Hansen

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Michael Kurz · Guest

"Thomas Hansen" <polterguy (AT) gmail (DOT) com> schrieb im Newsbeitrag
news:101a1348.0410250652.76b2c74f (AT) posting (DOT) google.com...

Victor Bazarov · Guest

Thomas Hansen wrote:

Balog Pal · Guest

"Thomas Hansen" <polterguy (AT) gmail (DOT) com> wrote

Thomas Hansen · Guest

"Michael Kurz" <mkurz (AT) move-multimedia (DOT) com> wrote

Thomas Hansen · Guest

Victor Bazarov <v.Abazarov (AT) comAcast (DOT) net> wrote

[snip]

Thomas Hansen · Guest

"Balog Pal" <pasa (AT) lib (DOT) hu> wrote

Craig Henderson · Guest

"Thomas Hansen" <polterguy (AT) gmail (DOT) com> wrote

Hi Thomas,
I understand your goal, but I wonder if you're making life more complex than
it needs to be. It's a neat trick, but the compilation errors are will show
the line of reference to WidgetType::canBeMaximized rather than the real
error line, which is the point at which the 'user' calls maximize() on a
concrete class that cannot be maximised.

Thomas Hansen · Guest

JKop · Guest

How about:

class AspectSizable
{
public:
// Implementation left undefined since it's of no importance
void setSize( unsigned posX, unsigned posY, unsigned sizeX, unsigned
sizeY );
void setWidth( unsigned newWidth );
/* etc... */
};

class AspectSizeable_CanMaximize : virtual public AspectSizeable
{
void Maxamize();
};

class AspectSizable_CanMinimize : virtual public AspectSizeable
{
void Minimize();
};

class AspectSizeable_CanRestore : virtual public AspectSizeable
{
void Restore();
};

class WidgetDialog : virtual public Aspect_Sizeable, virtual public
AspectSizeable_CanMaxamize, virtual public AspectSizeable_CanMinimize,
virtual public AspectSizeable_CanRestore {};

or something along those lines...

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Terje Slettebø · Guest

"Thomas Hansen" <polterguy (AT) gmail (DOT) com> wrote

M Jared Finder · Guest

Thomas Hansen wrote:

Thomas Hansen · Guest

Hi Craig, you are "almost" right and it probably might have several
advantages that the Magic Enums don't have, this only proves the
flexibility of the language, one problem a zillion solutions, but...

I am not sure if you ment the inheritance from AspectSizable to be
private, if you did not you can still inherit from the WidgetDialog and
use "maximize()" in derived classes (which in SmartWin is "the way to
use widgets" and exposes non functional member functions)

Still if you make the inheritance private and declares using maximize
in WidgetDialog you're in trouble...

For one you have a solution which will "default to allowance" for the
next widget you create and derive from AspectSizable, while the Magic
Enums will "default to deniance", kind of like being "secure by
default"...

Secondly, AspectSizable again may inherit from other classes which you
want to expose as public, this will make for a lot of using
statements...

At the end of the day the Magic Enums are declarative and you have to
intentionally mezz them up to do something wrong with them while the
private inheritance/using pattern is not and you will have to
explicitly make code around them to make them "safe"...

Not to mention the gain you can get if you bring this into a hierarchy
of classes where you can "pass the Policy Class around" to give other
classes access to the policy...
Plus you can derive policy classes from other policy classes...
Plus you can choose if you want to inherit from the Magic Enum
container class which gives you the opportunity to put code into them
(you can off course anyway)...

Example:

struct AllowMaximizing
{
enum can Maximize;
};

struct AllowMinimizing : public AllowMaximizing
{
enum canMinimize;
};

struct AllowDissappearing : public AllowMinimizing
{
void makeDissappear();
};

template<class VisibilityPolicy>
class AspectReallyFancy : public VisibilityPolicy
{
void minimize()
{
canMinimize;
/*... implementation ...*/
}
void maximize()
{
canMaximize;
/*... implementation ...*/
}
// We also get the makeDissappear here if policy is of right type...
};

class WidgetEverything : public AspectReallyFancy<AllowDissappearing>
{/*...*/};

or...

class WidgetAlmostEverything : public
AspectReallyFancy<AllowMinimizing>
{/*...*/};

class WidgetTheLeast : public AspectReallyFancy<AllowMaximizing>
{/*...*/};

or this one which is one of my favourites...
;)

template<class CustomPolicy>
class WidgetSomethingUnknownDefinedByUser : public
AspectReallyFancy<CustomPolicy>
{/*...*/};

Not to mention that you can make your own ones and combine the ones you
want to support...

struct MyAspectPolicy
{
enum canMinimize;
};

class WidgetCustom : public AspectReallyFancy<MyAspectPolicy>
{/*...*/};

It's another card up your slieve, it makes you able to do some things
more clean and easy then you could do otherwise...

Think of the possibilities you gain if you think of them as union
objects...

struct Int
{
enum Int;
};

struct String
{
enum String;
};

struct Complex
{
enum Complex;
};

struct ComplexString
{
enum Complex;
enum String;
};

template<class Type>
class OsCustomClipBoardRetriever : private Type
{
public:
Complex getClipboardComplex()
{
Complex;
/*...*/
}
String getClipboardString()
{
String;
/*...*/
}
Int getClipboardInt()
{
Int;
/*...*/
}
};

Now if you think that you might achieve the last one with a pure
template class with only the type of object retrievable from clipboard
you are "kind of right" until you realize that the clipboard might have
some kind of builtin functionality of getting e.g. a Complex out as
both a Complex AND a string while the Int can only come out as an Int
etc...

I think Magic Enums are really cool once you have "shaken off" some of
the cold from the past which denies you to do things like "combining
classes" since it's considered bad because it breaks alot of unspoken
laws like cohesion, encapsulation etc...

Fact is if you start applying them you'll notice they actually
increases cohesion, encapsulation, OO and even ** LSP **...
In fact of the last 15 problems I have had in SmartWin i have solved __
5 __ of them with Magic Enums...
Not because I wanted to "show of" or something, just because they
happened to be the best tool for the job!!

Thomas

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Thomas Hansen · Guest

I didn't try to compile it, it was not my intention to produce correct
code, it was not my intention to prove that it would give less code or
less overhead then the alternative solution presented by you.
My intention was only to prove that a rectangle COULD be a square
without breaking LSP, and if you fix some bugs in the code I am pretty
sure that most people will se that I have managed that...
I am sorry if I didn't manage to convince you however...

The places where I have found them to be particulary useful though is
in interop with OS functions (they probably apply usefulness though to
ALL libraries/API's written in C, Corba or COM though), like for
instance a HWND in Windows API you have NO WAY to tell compile time if
it's a Button Control, Drop Down List control or a Dialog, the only
difference is that they are created with different parameters
(CreateWindowEx( "EditControl" ), CreateWindowEx( "DropDownList")...
While a dialog can be maximized this doesn't make much sense in a Drop
Down List.
And in my class hierarchy in SmartWin (http://smartwin.sourceforge.net)
I use them as Policies to give widgets access to some (but not all,
depending on their inner type) functions which are wrappers around
Windows API functions.
The only datamember you have access to there is anyway only a HWND and
nothing else, and out from that HWND data member you are supposed to
let the user of the library call Windows API functions.
Some of them are universal for all HWND's while others only make sense
for some specific types of HWND's (which you can't know during compile
time)
In such a scenario I cannot see a concept which is better or carries
less overhead or less code then the Magic Enums...
It's actually quite stunning that SmartWin is almost a complete GUI
library for Windows with less then 15000 lines of code...

And btw, regarding the Rectangle/Ellipsis classes I think that mostly
these days they are being used anyway as wrappers around DirectX or
OpenGL or some other API where you also only have access to a "handle"
of some sort which is the same for a flat circle and a complete 3D
human being with joints and animations.
In such a scenario too I think that the Magic Enums would give you
serious gain in restricting the user by not letting him get to call
"Fly()" on a "handle" which is pointing to a submarine...

Thomas

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]