JeroenDeDauw added a comment. It's generally good to design interfaces from the perspective of their users. This is done by looking at each user and determining what would be best for them, as opposed to trying to come up with an interface that suits all users (including those that do not exist yet). The existing provider interfaces serve their users well, and have optimal interface segregation (their users do not end up depending on stuff they do not need). If there is a new class of users, namely those where immutability is not desired, then creating a new interface is typically better than making the interface less ideal for both users and implementers.
I think that looking at the number of interfaces one introduces is a very bad way of gauging complexity and maintenance cost. These come from the new functionality (the mutability) and the coupling caused by it. I'm a bit worried about the contract of the existing method though. It says no guarantee of mutability is provided, which means no guarantee of immutability is provided either. Users might use mutability they should not rely upon without this being noticed. After all, tests will pass, and the violation is not obvious, esp if the programmers are thinking about a specific concrete implementation where mutability is guaranteed. They have have to notice the docs in the interface. One way around this later concern is to have a dedicated interface for the case where users do not need mutability and implementers might not be able to provide it. In this interface the contract would be guaranteed lack of mutability. Users that would need mutability would use a different interface that does not, and this is key, derive from the other one. This interface would guarantee mutability. I'm not aware of which users you are trying to cater to, or what kind of implementations you have in mind. It depends on these what the best solutions are. TASK DETAIL https://phabricator.wikimedia.org/T126152 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JeroenDeDauw Cc: daniel, JeroenDeDauw, thiemowmde, Aklapper, Bene, StudiesWorld, Izno, Wikidata-bugs, aude, Mbch331 _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
