I realized something about Structured Data and writing plugins for it: the adt decorator is inspired heavily by the dataclasses module, so I should just... look at the plugin to figure out what's going on there.
What I've worked out so far is that I've changed things enough that a straight copy and paste is mostly not a good idea. I'll try to summarize what's going on when the adt decorator hits a class:
- The decorator takes three boolean options: eq, order, and repr. repr is irrelevant to the plugin.
- If eq is true, the decorator will attempt to add predefined equality methods to the class. It will not add them if the class itself defines them, but it ignores superclasses, and hm. Hm. I'm not sure that's right. In fact, I'm so weirded out by that behavior that I just now published a version where it takes superclasses into account. If the prewritten equality methods are added, it also attempts to add a prewritten hash method.
- If eq is false, the baseline behavior of equality methods is that of object. Also, it is an error in these circumstances to pass order=True.
- If order is false, the comparison methods bottom out at None, which... might be wrong? I'm honestly not sure.
- If order is true, it is an error if the prewritten equality methods weren't added. If they were, then the decorator will attempt to add predefined comparison methods. If comparison methods are already defined, that is an error.
For the methods mentioned here, the self and other parameters should be constrained, not to the same type as each other, but to subclasses of the decorated class.
Other things going on: annotations with a particular type indicate "constructors", which should be modeled as functions accessible only to the decorated class. I don't know if there's a good way to represent that sort of thing.
It looks like I've got two main areas to cover, and I think the way to get started on them is to start adding pseudocode in comments and figure out how to implement them. For now, it's late, and I should sleep.