Re: [boost] Re: Proposal: Design patterns library

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 
ignorance.

   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' 
pattern?

   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 
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.'

Sincerely,
Sreekant

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx