[boost] [GSoC] Patterns - interest check

Subject: [boost] [GSoC] Patterns - interest check
From: Kornel Kisielewicz (kornel.kisielewicz_at_[hidden])
Date: 2010-04-06 06:05:23

Hello all,

I'm (obviously) interested in joining boost as part of GSoC 2010.
Apart from a repeated try of generating interest in the Boost.Matrix
library I proposed last year (I'll probably post about it later), I'll
share an idea of mine that has been around in my head since I was
introduced to boost several years ago.

It all began with the singleton pattern -- we were writing a project,
and needed a singleton base class quick, hence the first place we
turned to was boost. There, two surprises awaited us -- not only
wasn't there a singleton library easily available, but in the boost
sources there were several singleton base class implementations, few
of them even exact the same.

True it is that singleton implementations differ - we want to be able
to sometimes control the initialization time and initialization order,
we sometimes need thread safety, and sometimes not, we'd like to
control how to handle creation, and how to handle referencing to a
dead singleton -- obviously a bloated master-class is not the solution
-- a policy based singleton template however would be.

Once that came into my mind, I couldn't shake the idea of a general
Boost.Patterns library. While indulging in a discussion of whether
Patterns are beneficial or not isn't my goal, we must admit that they
are commonly used, and several of those are already present in Boost
in one form or another (signals and flyweight comes up to mind as an
obvious example). Boost.Patterns would serve as a library for
collecting those patterns that aren't big enough for their own
library, and encompass the smaller  class traits (like
boost::noncopyable) too.

Apart from the singleton, one obvious candidate for such a library
that I'd like to code are the factory patterns, including the abstract
factory pattern. A policy based implementation of those might provide
a nice benefit for boost users not wanting to reinvent the wheel.
Further out, there are a few more commonly used patterns that would be
beneficial for a boost::patterns user. The way I see it, for the more
complex solutions, some framework of base classes to be used would
have to be designed, and then used between the patterns.

Mind you, I'm not trying to convince anyone to the creation of a new
Boost.Patterns library (although I'd really like to do that if
possible), instead I'd like to ask you if there's a viable GSoC
proposal in this post, one that one day might turn into a useful part
of boost.

-- 
regards,
Kornel Kisielewicz
http://chaosforge.org/