Resolve overlap between add methods

[Midnighter]

Some models in the Java client are designed to have a general .add method as well as more specific .add_person, .add_container, etc. methods. In general, it seems like these methods are slightly redundant and thus present some uncertainty in their interface.

I would like to analyze the use-cases and possibly make some simplifications.

[yt-ms]

Agree this is confusing. Taking Container as an example, you can add an existing Component via add() or by passing it to add_component(), or you can create a new Component through add_component() also.

I'd suggest restricting the add_blah methods to only create new blahs, i.e. not take an existing blah.

Another useful addition (pardon the pun) would be to add __iadd__ as a more pythonic version of the generic add, but both are of limited use whilst the parent argument is mandatory. Even better would be if we allowed parent to be optional and make add automatically set the parent and model, allowing code like:

container = Container(whatever)
container += Component(name="component1")
container += Component(name="component2")

rather than the current

container = Container(whatever)
container.add_component(name="component1")
container.add_component(name="component2")

Note that the add method should automatically set the model and parent in the added element.

[Midnighter]

I'd suggest restricting the add_blah methods to only create new blahs, i.e. not take an existing blah.

With __iadd__ allowing to add existing components this could be a nice change, yes.

Question then is, do we need a general add method at all, since this is then covered by +=?

[yt-ms]

Question then is, do we need a general add method at all, since this is then covered by +=?

Good point. I just checked the Java implementation, and the add methods there aren't public so we don't even need to keep add to stay consistent with that.

[Midnighter]

:man_shrugging: