[Mono-dev] another corcompare patch to hide extraneous"IsVirtual"differences

[Kornél Pál]

Hi,

Of course people assuming unusual things or depending on bugs will suck
anyway and I usually don't support their nonsense but if we allow this
difference different IL code will be generated from the same source code on
Mono and MS.NET because the referenced assemblies would have different API.
Having internal interfaces is not a problem. The problem is when the virtual
status of a publically visible (public or protected) method differ between
MS.NET and Mono as that results in different IL code and behavior on Mono
and MS.NET. So IsVirtual has to match MS.NET without regard to IsSealed or
to anything else.

And there is another case:

When MS.NET has a public virtual method with the name of and interface
method by that interface method is implemented using private method syntax
while we implement this as a single method there will be difference when
overriding the public method. On MS.NET interface method will not be
affected by the overriden method but on Mono both methods will be overriden
by the same method as it is a single method on Mono.

As a conclusion I think corcompare should show all differences in interface
method (of course property and event helper methods as well) implementation
syntax (public method with same name or private method with full name) to
ensure compatibility. (Of course only for publically visible interfaces as
we don't want to support people who are using reflection to manipulate the
internals of objects.)

Kornél

----- Original Message -----
From: "Atsushi Eno" <atsushi at ximian.com>
To: "Kornél Pál" <kornelpal at hotmail.com>
Cc: "mono-devel mailing list" <mono-devel-list at lists.ximian.com>
Sent: Thursday, November 03, 2005 11:12 PM
Subject: Re: [Mono-dev] another corcompare patch to hide
extraneous"IsVirtual"differences


> Hi,
>
> Kornél Pál wrote:
>> Hi,
>>
>> I understand your point of view why this case could be treated as OK but
>> there is big difference between virtual and non-virtual methods. The most
>> important and most relevant difference is that compilers (should)
>> generate
>> virtual calls for virtual methods and non-virtual calls for non-virtual
>> methods even for sealed classes. If corcompare ignores this difference
>> that
>> will result in different code for calling the methods that is something
>> bad.
>> In addition if these classes become non-sealed in later MS.NET versions
>> (there are some such classes in MS.NET 2.0 that are non-sealed but were
>> sealed in 1.x) or non-virtual methods become virtual the code will behave
>> differently as virtual functions can be called using non-virtual IL code
>> that results in the specified method instead of the virtual method that
>> is
>> something very bad.
>
> Oh, good point. But that also sounds like those differences are
> basically expected (between runtimes), thus it is not something we
> must pay attension. Those people who depends on such tip of the
> snow will be kicked by Microsoft when they compile their apps on
> .NET 1.x and run them on .NET 2.0).
>
> However, I agree with you that it could matter and had better
> be fixed.
>
>> So I think we should implement interface methods using the same syntax
>> (using full name privately or using public methods with the same name)
>> for
>> full MS.NET compatibility.
>
> Based on your points (and if I am correct), I think we had better warn
> if those methods are non-virtual while MS ones are virtual. I have no
> idea that virtcall could result in inconsistent call; we should anyways
> keep warning on overridability (besides virtcall performance difference,
> but I don't think it is something that should be warned in corcompare).
>
> I don't think that internal interfaces (such as IConfigXmlNode I
> mentioned before) should be warned as significant differences,so I
> don't think warning every differences out is a good idea. (There are
> also such classes that were added new interfaces in .NET 2.0 while
> there weren't such in .NET 1.x.)
>
> If this sounds reasonable, I'll bring another patch again.
>
> Thanks,
> Atsushi Eno
>
>>
>> Kornél
>>
>> ----- Original Message -----
>> From: "Atsushi Eno" <atsushi at ximian.com>
>> To: "mono-devel mailing list" <mono-devel-list at lists.ximian.com>
>> Sent: Tuesday, November 01, 2005 11:07 AM
>> Subject: [Mono-dev] another corcompare patch to hide extraneous
>> "IsVirtual"differences
>>
>>
>>> Hi,
>>>
>>> As implemented in the previous patch, corcompare now shows
>>> abstract/virtual/static differnces on methods (including property
>>> accessors).
>>>
>>> Now it uncovered the difference on how we implement interface
>>> methods on each class. Say, there is only one Clear in our
>>> System.CodeDom.NamespaceImportCollection.Clear(), while MS.NET
>>> has two Clear() (one is an implicit implementation).
>>>
>>> One another case, there are some internal interfaces that
>>> commonize some members (for example, ConfigXmlDocument that implements
>>> IConfigXmlNode, in System.Configuration, has different IsVirtual
>>> attribute on Filename property).
>>>
>>> Those differeces come from the fact that a MethodBase.IsVirtual is
>>> True for such a method that is part of an interface implementation.
>>>
>>> They are not significant differences that we should care.
>>>
>>> Thus, the only differences we should care is whether they are
>>> overridable or not. It prints "should (not) Overridable" instead of
>>> "should (not) be Virtual".
>>>
>>> Based on the premise above, I created another corcompare patch.
>>> This time it won't show such annoying differences.
>>>
>>> Does it sound fine?
>>>
>>> Atsushi Eno
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>