I didn't send it immediately after I wrote it (as the hotel was disconnected) and anyways I didn't feel I have to reply to this fruitless post immediately. But as you requested, here it is.
Gert Driesen wrote: > This is not making much sense. Just about every member/class in > System.Xml.Serialization is marked like that. > Developers using that (eg. for our web services stack) must then indeed be > real idiots. Yes they are idiots, as long as they depend on internals. You are trying to imply that I meant EVERYONE who use XmlSerializer is idiot, but that's totally wrong. > Marking a class or member as ".NET Framework infrastructure" means you > should avoid using it in user code as its behavior is not documented and > subject to changes. However, it's of course perfectly valid to use those > classes from within the ".NET/Mono Framework infrastructure". > > In this specific case we're talking about an interface that by itself does > not have any logic. But should the usage of that interface related to > ConfigurationErrorsException change, than my unit tests will allow us to > notice that. > > With my change, my goal was not just compatibility with MS. The only reason > why - in this case - compatibility was nice to have, was to get unit tests > that pass on both Mono and MS. Yes your goal was just compatibility. The tests just asserts that. There is no additional value. Having compat tests for internal-only is bad because Microsoft is 1) either not ready to provide fixed API and likely change in the future, and/or 2) they do not provide enough documentation and that fact blocks us from implementing .net-compatible components. In such situation we rather choose quick functional and effective implementation that saves reasonable mortals. Sticking to compatibility does not save anyone and hence such people just leave extraneous tests. Having extraneous tests 1) blocks maintainers who are often responsible (unlike you) to go further development and 2) costs everyone extraneous time for patch reading. Hence it goes below the balance point. Well, probably it won't be understood by those who were never flooded with extraneous patches and were cost their precious time. > I can't see why implementing a public interface is worse than using an > internal interface in combination with checks for a specific class for the > exact same purpose? Public or non-public is really insignificant here. Atsushi Eno _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list