From: John Carter <john.carter@...>
Date: 2005-08-02T07:58:00+09:00
Subject: C++ Design Principles for Ruby - Classes of Classes.

I have just been reading "C++ Coding Standards" 101 Rules, Guidelines, and 
Best Practices" by Herb Sutter and Andrei Alexandrescu.

Some of the stuff is boring bog standard, the grist of a 1000 coding 
standards.

Some of the design principles have been articulated in many different 
places, but I wonder about their applicability to Ruby. I suspect some may 
be restated in a Ruby Way.

Here is one that is very C++ specific, yet I suspect there is a kernel of 
value that could be extracted into a far more Rubyish flavour.

So to get at the Ruby flavour, I will be spitting out the relevant items 
in a series of messages.

===Quote========================================
Item 32. Be clear what kind of class you're writing.

Different kinds of classes server different purposes, and so follow 
different rules...

Value classes (eg. std::pair, std::vector) are modeled after built-in 
types. A value class has a public destructor, copy constructor, and 
assignment with value semantics. It has no virtual functions, is a 
concrete class, not a base class.

Base classes are the building blocks of class hierarchies. A base class 
has a nonpublic copy constructor and assignment operator. Establishes 
interfaces through virtual functions. Is instantiates as part of a 
concrete derived object.

Traits classes are templates that carry information about types. Contains 
only typedefs and static functions. No modifiable state or virtuals. Not 
usually instantiated.

Policy classes are fragments of pluggable behaviour. Usually not 
instantiated standalone, but only as a base or member.

Exception classes.

===================================================

My commentary.

I often start doing something like...
   class MyHashLikeThing < Hash
   end

and end up refactoring that to
   class MyHashLikeThing
     def initialize
      @data = Hash.new
     end
   end

So I guess he's right about value classes. I think he is probably right 
about creating public copy constructors (clone method?) and assignment 
with value semantics.

Just because we don't do generics, doesn't mean that we don't have traits. 
So I suspect he is right about them too.

I think mixins are where policy classes fit in.

John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.