I’ve run into some design flaws regarding how components are identified and removed from the survey. Emma and I agreed that the current component ids should remain hidden from the user and be used only for internal representation, but the issue of how to identify components when trying to remove or find them in the survey remains. Over the weekend, I changed all of the removal methods for each component so that they took an object pointer as an argument, rather than the id of the component being removed, under the assumption that this would be more intuitive than keeping track of arbitrary component ids. However, this poses an issue if the user only has a pointer to the top level survey object (for example, in my test suites, the example surveys are created externally and returned as a single survey object; the test module has no pointers to their inner components). This method also poses an issue if, for example, components are created and added to the survey using list comprehensions, and the user does not retain a pointer to each individual component.

After discussing the above issues with Emery and Emma, we have determined that the functionality for removing questions is unnecessary, and can be removed. My initial assumption of the library’s usage was that a user may want to create several versions of a survey, in which certain questions, blocks, or other components may be added, removed, or changed. We decided that this is no longer the case, and that the library does not need to allow for the alteration of surveys. It exists for the user to program a single survey and obtain the corresponding JSON representation of that survey; any different surveys can be programmed separately, and there is no need to be able to load and alter an existing survey. Given these assumptions, I will focus my testing on everything else and ignore the removal methods (I’ll probably delete them eventually, as long as I’m sure they’re no longer necessary).