programming

sealed is the worst

the justification for the sealed keyword is so the compiler can do extra optimizations such as turning some virtual methods into non-virtual methods..

unfortunately it is a disaster as far as object oriented programming is concerned imo.

damn it.. if i want to derive a class.. fucking let me. for instance..

winforms has a Graphics class that is sealed... say you want to wrap it. instead of this..

class NativeGraphics : public System::Drawing::Graphics
{
};

you get this..

class NativeGraphics
{

//-- 50 thousand methods calling _graphics->something

protected:
System::Drawing::Graphics^ _graphics;
};

terrible.

so why would you want the top example?

class PaintContext
{
protected:
ref class NativePaintContext^ _nativePaintContext;
};

this allows the PaintContext header to have no knowledge whatsoever of the underlying native implementation of the paint context. all platforms can share the same headers without #ifdef macro madness everywhere. this comes at the cost of an extra indirection (well 2 now that it is fucking sealed), but i don't care, none of this code is performance sensitive.. if it is.. you've got a design problem.

now the big question is will i get sick of writing stupid method wrappers override my distain for macros all over the place?