Re: [boost] GSoC 2010: Heaps and Queues

Subject: Re: [boost] GSoC 2010: Heaps and Queues
From: Dan Larkin (danielhlarkin_at_[hidden])
Date: 2010-04-09 11:36:14

Andrew Sutton wrote:
> Developing concepts is not a top-down process, nor is it a "chicken and the
> egg" problem. One way to look at concepts is that they describe common
> features of related kinds of types, although there is a much more precise
> way of saying this. How do you know the commonalities of heaps and/or queues
> if you haven't implemented any?
> 
> It's always possible to guess, but why spend the time? The project is to
> implement data structures, not describe them.

Well, maybe I'm taking a non-standard development approach, but for me 
the design process goes something like this:

- Research algorithm/structure
- Determine required functionality
- Design interface to reflect the relationship between the theory and 
the implementation

If the previously established theory (which describes the structure) 
groups a set of structures into a concept and group of "models" (sure, 
they're still concepts themselves, but...) that all have a well defined 
set of commonalities, it's not much of an issue to determine what they 
are, is it?  And doesn't a good design from the beginning make the 
development process easier as time progresses?  You end up with a much 
more coherent library if you have a well-designed interface to which the 
implementation conforms rather than an implementation that has an 
interface slapped on top.  And of course you can then define an 
interface later and adapt all the pre-existing structures to match it, 
but again - if you know at least approximately what the interface should 
look like, why not start with it in mind?  It keeps the code much cleaner.

I know that I can't say I've implemented all the heaps.  Nor can I say 
that I know exactly line for line how I will do so.  But I can say that 
I know approximately what functionality I want out of them, and this is 
what I am trying to reflect with the abstract base class.  It is still a 
draft interface, and subject to change as I begin implementing the 
various structures and seeing how differences may help to make the 
library better.  But I think it does need to exist from a design 
decision standpoint.

Dan Larkin