[Mono-dev] [Fwd: [Mono-patches] r106626 - in trunk/mcs/class/System.Configuration: . System.Configuration Test/System.Configuration Test/standalone]

[Atsushi Eno]

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