Some ideas for specifying mobject defaults and inheritance

[markromanmiller]

Motivation

In the past week or so I've been noticing quite a lot of weird things regarding manim object properties. Bug #1020 is one example, but in the same vein @friedkeenan pointed out on Discord that ScreenRectangle doesn't work as expected because Rectangle.__init__ overrides some important values.

Overall, it seems like the trouble might stem from either the CONFIG rewrite (#783 - no blame, CONFIG needed to go) or just the general messiness of inheritance (in both the class hierarchy sense and the scene hierarchy sense).

I'd like to collect my thoughts on inheritance and defaults here, and encourage conversation on what makes sense going forward. I'm still pretty new to the repo, so I would really value other's thoughts.

Ultimately, the goal is to set up the inheritance system under the hood so it's a lot harder to introduce bugs like the two mentioned above.

Vision

It's important to start by naming what the default mobject property system is for, to keep the goals in mind. Two of these are done pretty well at the moment, one is not.

• smart defaults for mobjects, so that animations can be made quickly and iteratively
• set properties for a specific object, because - well, duh.
• set default for a class of objects so that animators can quickly and concisely create an aesthetic for their own videos.

From previous iterations, there are a couple important lessons to keep in mind when we're modifying the new system.

• Minimal changes to [reasonable] current behavior.
• Explicit is better than implicit (as one of Python's maxims). One of the problems with CONFIG (as I understand it - refering to @leotrs on this one) was that the arguments weren't explicit and so couldn't be parsed by IDEs.
• Priority should be given to the more specific set of properties (this is like CSS).

Which defaults take priority?

One thing to note is that this would be straightforward if there was only one type of inheritance, but there are two - the classes and the scene graph. For example, a Cross is a subclass of VGroup but its objects are Lines.

Ultimately, though, I have something I think makes sense. From highest to lowest priority:

1) Properties set imperatively, e.g, thing.set_color(RED) (or thing.color=RED after #787 is completed). 2) Properties set in the scripter-facing kwargs of a Mobject or a Group, like Line(color=BLUE) or Cross(obj, stroke_width=24). 3) Properties set in the file the object is loaded from (really only applying to SVG files here). 4) Property class defaults set imperatively, e.g, Square.color = RED at the top of a scene file. Highest priority is the current class, with decreasing priority up the class hierarchy. 5) If we allow .cfg files to specify class-level properties, then they would have priority here. Again, more specific classes take priority over more general classes. 6) Hard-coded defaults within the class's source code, aka the community-wide default, and on up the class hierarchy.

Implementation

For implementation, I have some initial thoughts. Not all of these are exclusive.

• To enable class defaults, it might make sense to have class properties. I did a smidge of testing and it looks like inheritance works the way you'd expect with class properties, as long as the class properties aren't mutable. I'm not sure whether it's pythonic, but I would hope someone knows that well enough here (@leotrs?)
• I think it would make a lot of sense to have color, stroke, and other defaults for classes enabled within the config files. When I first learned about config files I thought that's what they were for, and I was slightly disappointed that's not how it worked.
• A final stray thought is to consider having the property passing as **kwargs within the init function signature, but explicitly listing off all the properties either as a class property or within the __init__ call. It might make merging of the property dictionaries a lot easier, while also keeping the properties visible to the IDE (and therefore the user)

Some tricky cases came to mind:

• How should a Square that is a submobject of a Line be colored - by its Square [class] default or its scene-hierarchy-parent Line coloring? I think it should be its square coloring, and there should be a test case for that in particular.
• Is None ever used as a meaningful parameter, rather than the lack of a parameter? If so, that might make it really difficult to specify explicit nothing-was-set-for-this-parameter as None.
• What if a user wants to specify all rectangles a certain color, but leave the Riemann rectangles in GraphScene their default color? It might be possible to create a stubbed subclass of Rectangle and specify its default that way, but another option is specifying that rectangles under a RiemannRectangle group shouldn't be colored...
• What to do about double class inheritance (do we have any objects of that type?)
• Some objects set their submobjects's colors imperatively within the class, e.g. GraphScene. Where does that rest on the hierarchy? I think (1) and (2) obviously apply, but should it be influenced by (4) like Rectangle.color=RED or (5) in the config file? And what if there was a specified default, in, say, a config file entry (5) for GraphScene's default_start_color? Would that trump the less specific but higher priority class-default-in-file (4) for rectangle color?

[huguesdevimeux]

Hi,

Some trow-on-paper thoughts about this.

• The main issue with using class default is that it will block the use of class @ property (using both is not possible). (And, to answer your question, if the type is mutable, then class attributes can be modified at instance level, but on second thought there are not that much mutable attributes).
• I'm against using this in the current .cfg, and I'm pretty sure that @leotrs agrees with me : I don't remember his exact words but he said during the creation of the config system that it aims to handle everything that is not represented in the scene (ie, width, frame rate, log level, etc (the "meta scene" stuff).
• I didn't really understand the double inheritances thing. What do you mean by there are two different inheritances? If you meant by that the link with VGrouo and their submobjects, I see, then it makes sense that the VGroup has the priority over the setting of the attributes (during instanciation, at least).
• I don't think there are mobjects with double inheritance (but I can be wrong!). If there are, they should likely be removed as I don't see how they can fit properly in the architecture.

To conclude I don't think implementing such thing is a good idea in our situation. As you mentioned, there will be logical issues and will probably get use closer from the old world with CONFIG that getting us far from this.

Thanks for this :D

[markromanmiller]

Thanks for the feedback. So most of the specific implementation ideas don't seem to make sense one way or another. That's good to know.

What do you think about the goals, though?

To perhaps talk about the motivation in a different way: I think it's error-prone to do this property-passing and property-setting the way we have been doing it. I don't seem to notice any rhyme or reason for which properties are attributes and which are not, which are explicit and which are in **kwargs, when to overwrite properties and when to not, etc etc.

[huguesdevimeux]

I'm not sure to follow you. Could you show an example ?