[Mono-devel-list] CLS compliance

[Atsushi Eno]

> Its not really a Pascal compiler bug btw. (besides that the "error"
> should be labled a "warning", which is currently under discussion)

Oh, OK there's "NOTE" lines in the first post.

>>> I did not try to find out what CLS compliancy requirements are not met
>>> in detail, but there is one which causes this class to be less usable
>>> with some .NET languages:
>>
>> This is not true. Microsoft VBC did not complain anything.
> 
> Huh? Where did I mention VBC? Even if it did not complain, it does not
> mean that this works. Did you try to access line *and* Line from VB?

Huh? you said general "some .NET languages" so I just put one
case insensitive language as an example.

>>> ps: the [CLSCompliant(*false*)] correctly declares  that piece of code
>>> to be non-compliant, but of course it does not make Pascal-compilers
>>> case-senstive ;-)
>>
>> This should not matter. Those case insensitive compilers should
>> avoid to examine those non-CLSCompliant types.
> 
> You are missing the point: If you have identifiers in *protected* or
> *public* interfaces which differ by their case only, how should a
> case-insensitive compiler access them? As long as you do not *touch*
> them, the compiler still can produce the code though. (Basically VBC
> just *hides* the fact that there are inaccessible things)

I don't understand why you stick to the conclusion that those
case insensitive languages can, or must be able to, access to
non-CLSCompliant types without problem, without "discussion if
casesensitivity makes sense or not".

> "Must not" is relative - in private sections, you can do whatever you
> want, but public/protected interfaces are the problem here - if
> portability is one of the goals.

Portability vs. API stability; I agree that those member
signatures are good but what you are claiming is to change
public interfaces that is already published.

I think this change should not be done, since that type
*explicitly* says that it is not portable and thus people can
expect what happens if they try to use it, while those people
who already use those members in MiniParser should not get
stuck with *unexpected* API changes.

BTW if you are using MiniParser it is not maintained anymore. In
this case you could copy SmallXmlParser from mscorlib and use it
instead (this time really, unlike Matthijs' case).

Atsushi Eno