M
Mitchell S. Honnert
I'm thinking about adding unsigned types, like UShort and UInt, to a VB.NET
library that I published which edits ID3 tag information. It would make the
interface much more clean to have some properties of my main class like
TrackNum and Year be UShort instead of Short. I wouldn't have to check for
negative values; the data type itself would simply preclude the use of
negative values.
But of course unsigned types are not CLS-compliant. From the research I've
done so far, I see two general themes. One is "Always make everything CLS
compliant." The other is "Since you're using VB.NET, you're not truly
CLS-compliant anyway, so it doesn't matter." (The latter theme references
how not using the /novbruntimeref compiler directive would, in effect, make
an assembly not CLS-compliant.)
If given a choice, of course I'd want to make my library CLS-compliant so as
not to limit its potential audience. In theory, any CLS-compliant language
can consume a CLS-compliant assembly, but in practical terms, I see the vast
majority of applications using my library as being VB.NET or C#. So, right
now I'm trying to balance giving up what I see as a substantial improvement
against living up to a perhaps unrealistic goal.
Thoughts?
Mitchell S. Honnert
www.UltraID3Lib.com
library that I published which edits ID3 tag information. It would make the
interface much more clean to have some properties of my main class like
TrackNum and Year be UShort instead of Short. I wouldn't have to check for
negative values; the data type itself would simply preclude the use of
negative values.
But of course unsigned types are not CLS-compliant. From the research I've
done so far, I see two general themes. One is "Always make everything CLS
compliant." The other is "Since you're using VB.NET, you're not truly
CLS-compliant anyway, so it doesn't matter." (The latter theme references
how not using the /novbruntimeref compiler directive would, in effect, make
an assembly not CLS-compliant.)
If given a choice, of course I'd want to make my library CLS-compliant so as
not to limit its potential audience. In theory, any CLS-compliant language
can consume a CLS-compliant assembly, but in practical terms, I see the vast
majority of applications using my library as being VB.NET or C#. So, right
now I'm trying to balance giving up what I see as a substantial improvement
against living up to a perhaps unrealistic goal.
Thoughts?
Mitchell S. Honnert
www.UltraID3Lib.com