On Jun 6, 2008, at 3:49 PM, Ben Webb wrote:
> Daniel Russel wrote: >> I think we should have a new class of object, which I am, for the >> time being calling a ParticleRefiner to handle hierarchical >> collision detection and generation of particles on the fly. I am >> currently using it to generate particles to cover the edges of my >> unstructured chains in order to better preserve excluded volume. >> The interface looks more or less like: >> ParticleRefiner { >> // return a bunch of particles which refines p >> Particles refine(Particle p) >> // clean up the particles which refined p if needed >> cleanup(Particle p, Particles); >> }; >> And the methods must be called as a pair with the result of the >> first method passed as the second argument to the second method. > > Sounds reasonable to me. But what if the user passes a different > list to cleanup? It could be hard to check, true.
> What sort of bad things would happen? Why couldn't the Refiner just > keep its own list of particles? I need to be able to refine two particles (for example when doing collision detection) using the same refiner (or pass two identical copies of the refiner). As a result, the refiner would have to maintain a map internally, which seems a bit heavy since the external user has the lists already.
> Also, it seems like there's some overlap between this and > CoverBondsScoreState. Yeah, the logic from that would move into such a class.