On Oct 25, 2007, at 11:38 PM, Ben Webb wrote:
> Daniel Russel wrote: >> I have various helper functions that are probably generally >> useful. I am ambivalent about what to do with them. > ... >> bool set_string(... >> const String& get_string(... > ... >> Should such things go in to imp proper? On one hand they are >> extremely useful. On the other it is increasing the size of the >> interface and while it makes it more convenient, it doesn't add >> any power. > > My vote is no, for the same reasons. Plus, it seems like a > conceptual division between add/remove of the attributes themselves > and get/set of the values is a good thing to have, and these helper > functions would erode that. Can't you structure your code so that > you don't create the necessary attributes at the first step, and so > don't need to do this query every time? In certain cases it is much easier to not worry about whether it has an attribute yet and not practical to add every attribute that something might have and which you would need to use later. For example, if you want to add a child to a node, it saves a few lines not not have to check if the child count is there already or not.
> > I don't think we've agreed on how hierarchy should be handled yet. > Could you put an outline of your suggestion into the wiki? Then > Keren and I can tweak it and add our own ideas. I certainly have > reservations right now with how I imagine you think hierarchy > should be handled (guessing from looking at your attribute names > wiki page). I think the wiki page with the attributes says it all--it is just a general tree. You have parent and child "pointers", a counter for how many children and a parent index and a string naming what sort of thing you are. I am pretty sure we shouldn't have anything less general (unless we want to fix that a residue always has a chain as a parent) and unless you want to support DAGs, I am not sure what a more general thing to support is.