C++ Design Principles for Ruby - Classes of Classes.

Discussion in 'Ruby' started by John Carter, Aug 1, 2005.

  1. John Carter

    John Carter Guest

    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

    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.

    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

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

    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 :
    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.
    John Carter, Aug 1, 2005
    1. Advertisements

  2. Guest

    Cit=E1t John Carter <>:

    > I think he is probably right about creating public copy constructors (c=

    > method?) and assignment with value semantics.

    Hmm, I thought #clone makes a crude low-level copy, and #dup is the
    "higher-level" method for that, doing a shallow copy first, then calling
    #initialize_copy to do class-specific deep copy operations. Could someone
    clarify that for me?

    , Aug 3, 2005
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Carter
    John Carter
    Aug 2, 2005
  2. John Carter
    John Carter
    Aug 2, 2005
  3. John Carter
    John Carter
    Aug 2, 2005
  4. John Carter

    C++ Design Principles for Ruby - LSP

    John Carter, Aug 2, 2005, in forum: Ruby
    John Carter
    Aug 2, 2005
  5. Bil Kleb

    Ruby Design Principles

    Bil Kleb, Oct 26, 2006, in forum: Ruby
    M. Edward (Ed) Borasky
    Oct 27, 2006