J
John Carter
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:
air, 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 : (e-mail address removed)
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.
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:
air, std::vector) are modeled after built-intypes. 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 : (e-mail address removed)
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.