Boost logo

Boost :

From: Sreekant Sreedharan (blue_panther_at_[hidden])
Date: 2002-04-10 04:08:16

   My apologies, I am still trying to figure out how to use this mailing
list. I can't seem to get my mail to continue a thread. Please forgive my

   To begin with, I haven't read the book by Andrei. I just noticed the
reference to loki and found the library online.

   Let me present a few point I discussed with a fellow member of this
community. I am sure we are all in agreement on a few things.

1. A general purpose library should appeal to a maximum set of people, not
necessarily all..
The keyword is 'not all'. To put it simple, it follows the 80/20 rule. If it
does, patterns will be used as often as you use an STL vector, list or map.

2. A general purpose is simple enough to warrant its usage even by a
beginner. To put it plainly... 'Simplicity is the essence of art'

3. A general purpose library should probably be expressive enough to
establish a common vocabulary......
   As an example, when our comrade David Greene says-
"Gennadiy is right that PETAL doesn't cover the kind of things we'd
like to see in Boost (I particularly like the "sliceability" of Loki
abstract factories) but that doesn't go against the general idea of
a generic pattern library."
   Silly old me is sitting here thinking, 'oops! what the hell is
sliceablity', and scrambling around the web looking for what I am missing.
And in the meantime wondering... is he talking about a 'product trader'

   Please forgive my ignorance. But there are a lot of novices, who may be
interested is sharing thought (me for one :)).
   Hence any such library we choose to use to express common design
philosophies, has to be 'expressive' of the thoughts of the creator to even
a novice. To achieve this, it should not get jumbled in the lingo of the
many aliases we have for a common description of a pattern.

4. Not all patterns can be summarised into a library....
>From my experience with petal, some patterns tend to be applicable to
specific domains. And they hence cannot possibly satisfy the 80/20 rule.
(Common design patterns for CORBA, and the web for example).

5. Not all implementation can be generalised....
For example, the multitude of implementation of a singleton pattern, with
its tradeoffs, make it difficult to be generalised. (It is so simple, its
tough :)!!!!! ). But half the time, I am desperate for a singleton!!! I had
to settle for the simplest, rather than complicate it for the user!. (Am
still not happy with what I invented.. :) ).

6. A general purpose library has to be portable!......
Need I say more? :)

7. It should strive to ease the task of a programmer.....
Half the time I am writing a code, I am writing a manager. Today when I
write code, I often write it as...

class CSesssionManager:patterns::manager<CSession>

   ..without a worry about if it should be multithreaded, or have special
object behaviour like a COM or CORBA reference counted objects, dada dada
    Well, I could have easily implemented it as a vector, or list... but why
do I have to? when its an established pattern?... and secondly, when I write
that one line above, I am telling the reader, that this class is a manager
for sessions.... and she does not have to look at the file header, or the
documentation.. it is self expressive!!

   I persent these arguments in support for David's point.... and to quote
this fine gentleman...
'I believe there is enough "general" usage out there to warrant including
common patterns in Boost.'


MSN Photos is the easiest way to share and print your photos:

Boost list run by bdawes at, gregod at, cpdaniel at, john at