API naming

[letsar]

The naming of the classes and the methods may not be perfect. Before reaching a stable version, it's important to have a good api. This issue is created so that you can vote on these new namings.

Maestros

Some of you don't like to differentiate collections just by using the plural form. It is understandable. I want to make few suggestions, let me know what you prefer:

• [ ] MaestroCollection
• [ ] MultiMaestro
• [ ] MaestroList
• [ ] Keep Maestros

But maybe you prefer to have a different constructor instead of a new widget (but it would be a little 'hacky' in term of implementation):

• [ ] Maestro.multi
• [ ] Maestro.many

readAndWrite

The readAndWrite methods exist so that you can update a new value from the previous one without calling read before. This naming is maybe too long. If we would rename this, what would you like:

• [ ] update
• [ ] replace
• [ ] keep readAndWrite

Don't hesitate to make your own suggestions and I will edit this if necessary.

[lucasccustodio]

Hey interesting approach here, will certainly keep an eye to see how it goes, now regarding naming I think Maestros is easier to write and remember and update instead of readAndWrite works better imo. Also dunno if it's the right place to ask but I didn't see you explaining what a Performer does and it got me curious, so what are their purpose in this architecture?

[letsar]

Thanks! Concerning Performer, for now, it's just an abstract class for objects which want to be notified when attached and detached from the tree. It's here in case there is an alternative to Composer for other things, but if I don't find any use cases, I will remove it I think.