Currently just about everything the high level API offers is based on the idea of an XEditGenericObject, which treats all elements to be the same just with some slight variations on what methods are valid and what methods are not.
Turned out, "groups" vs "records" vs "subrecords" are very well defined ideas that I didn't know about back then, so it makes more sense to build some kind of class hierarchy based on these abstractions instead. So the next major refactor should refactor XEditGenericObject into XEditGroup, XEditRecord, XEditSubRecord, etc... and be a bit more formal on what methods are supported and what methods are not.
This refactor is mostly just to make the overall architecture a bit more sane, and largely should not affect users of the API, other than that maybe some of their objects now have different-looking reprs. If they were relying on a method previously - it likely means the method was a legal one for that element, which means it should still continue to exist after the refactor.
Currently just about everything the high level API offers is based on the idea of an
XEditGenericObject, which treats all elements to be the same just with some slight variations on what methods are valid and what methods are not.Turned out, "groups" vs "records" vs "subrecords" are very well defined ideas that I didn't know about back then, so it makes more sense to build some kind of class hierarchy based on these abstractions instead. So the next major refactor should refactor
XEditGenericObjectintoXEditGroup,XEditRecord,XEditSubRecord, etc... and be a bit more formal on what methods are supported and what methods are not.This refactor is mostly just to make the overall architecture a bit more sane, and largely should not affect users of the API, other than that maybe some of their objects now have different-looking reprs. If they were relying on a method previously - it likely means the method was a legal one for that element, which means it should still continue to exist after the refactor.