With the introduction of the breaking change in #238. AddClasses can no longer be used to bind internal implementations to public interfaces. This change doesn't seem to makes sense given the overload that accepts the publicOnly flag. To maintain higher flexibility and not to risk breaking changes.
I think #238 should be reverted and the docs should be updated to be consistent with the existing behavior.
If the publicOnly overloads did not exist I think a better case could be made to change the implementation, but given that they do, that is the mechanism that should be used to support both scenarios.
With the introduction of the breaking change in #238. AddClasses can no longer be used to bind internal implementations to public interfaces. This change doesn't seem to makes sense given the overload that accepts the
publicOnlyflag. To maintain higher flexibility and not to risk breaking changes.I think #238 should be reverted and the docs should be updated to be consistent with the existing behavior.
If the
publicOnlyoverloads did not exist I think a better case could be made to change the implementation, but given that they do, that is the mechanism that should be used to support both scenarios.