{"push_id":1044145237,"size":1,"distinct_size":1,"ref":"refs/heads/develop","head":"2fd821e92c5043d701ce5edf4ac1e51b22e2bc34","before":"0ad15727c7c0ce769876edad78725dae717e0cf7","commits":[{"sha":"2fd821e92c5043d701ce5edf4ac1e51b22e2bc34","author":{"email":"ea79b0961d255bf69a4c633ca17b6595df150ed7@gmail.com","name":"David Dotson"},"message":"Moved universe definition methods to own limb, changed selections to atomselections\n\nWe have to be careful that the namespace of a Sim doesn't become a\nliability in the future depending on what goes on in datreant. This is\none issue with the approach datreant takes with respect to limb-based\nfunctionality: namespace conflicts are very possible, and I don't have a\ngood policy in mind for how to resolve this long-term. At the moment\nthere's no issue because we don't have much going on, but we have to\nmitigate the issue now so it's not hell later.\n\nMoving universe definition properties/methods into their own limb limits\nthe possibility of namespace conflicts, since it's one name (udef) vs.\nmeany introduced into the Treant's top-level namespace. It also means\nthat later we can treat the universe definition as an object, and so we\ncan make a setter a la Tags for duplicating a universe definition\nbetween Sims.\n\nAlso, changed selections to atomselections in anticipation of the\nfuture. \"selections\" is too generic a name to use in an\napplication-specific package, as this could get used by a datreant\npackage later.","distinct":true,"url":"https://api.github.com/repos/datreant/MDSynthesis/commits/2fd821e92c5043d701ce5edf4ac1e51b22e2bc34"}]}