Closed mwchase closed 5 years ago
Okay, so:
Each Function and Property are associated with just one class in terms of ability to mess with them, but they cache an instantiation of their matchers that is unique for each class whose instances access them.
I may need to make Function and Method distinct things.
Note: __set_name__
is called before __init_subclass__
.
Need to have a proxy for Properties as well.
Special-case the class determination for Sums (go to specified superclass).
Not sure what's the best approach for Products.
Maybe it should be "whichever class is the owner can register itself (but does not have to), and any subclasses that are Sums can register themselves".
Something about that seems arbitrary, but I haven't yet come up with a pattern of usage that would be significantly messed with.
Maybe Products should only register if none of their Product superclasses are registered? Or, none of the superclasses between them and the definition in the MRO?
The difficulties I'm having here reflect my general feeling of "I'm not quite sure when placeholders should even be used with Products".
Maybe the recommended practice for using placeholders with Products should be, only if there's a constructor method that is defined on the mixin that uses the placeholder.
Maybe for now, the best thing would be to just stop Products from registering themselves until I figure this out.
The new design looks to be all set
The idea I had of defining mixin methods using placeholders seems solid, but it only makes sense for sum types.
How it should behave for product types is... iffy.
Like I almost think it should raise a warning to access a Function from a different class than it was defined in, or perhaps block it from allowing the decorators.
That sounds like a good solution.
I would like it to be possible to use them as mixin methods, which I believe isn't currently possible.