Re: [IMP-dev] More patches with a couple API changes

[Daniel Russel <>]

On Aug 8, 2008, at 1:19 PM, Ben Webb wrote:

> Daniel Russel wrote:
> > - The constructors for the nonbonded lists no longer take the  
> > radius key
> > as an argument. They default to XYZRDecorator::get_radius_key and the
> > value can be set using the set_radius_key method
>
> What if I wanted a particle to have more than one radius? It seems  
> like
> this would make such a thing impossible. I can certainly imagine  
> spheres
> with a 'hard' inner radius and a 'soft' outer radius, to allow partial
> penetration. And all atoms in Modeller have two radii.
I doesn't prevent you from doing that. It just doesn't aid you-- 
everywhere except the decorator can take an arbitrary key, the easy  
case is just now easier. Eventually it would be good to add a way of  
setting the key you use in the decorator for each instance of the  
decorator (probably by a custom version of cast, create and the  
constructor), but that can be added on later.

> Is there a reason why these are not static methods? Seems like that
> would make more sense, and give a cleaner namespace, e.g. rather than
> IMP::hierarchy_get_by_attributes(), use instead
> IMP::HierarchyDecorator::get_by_attributes().
They don't use privileged access to data or affect invariants, so I  
don't see a reason to make them members. Having them not be members  
also means that other similar methods that users add which use a  
similar level of access are called in the same way. (If they become  
members, they should become real members, not static ones since they  
take a decorator).

As for the name prefix, I am ambivalent about that. The names seemed a  
bit too generic without it, but it really isn't necessary.

> I can handle that - it's just a %init line in the SWIG wrapper. I'm  
> not
> sure why it should ever be true, actually. Surely if I throw an
> exception and then catch it somewhere else in the code that  
> exception is
> expected, and I shouldn't bother the user with it. Seems like only
> unhandled exceptions should be logged.
Yeah, but I don't know how to do that when debugging or using the code  
within C++ as the debugger and runtime environment don't print the  
message for unhandled exceptions. There may be some hook you can use  
to change that behavior, but I don't know it offhand.