Unsigned types and CLS-compliance

[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

[AMDRIT]

Do you need to support an unsigned value and force it as thus? Couldn't you
have the set modifier of a property enforce your desire to have positive
values?

Quote:

I wouldn't have to check for negative values; the data type itself would
simply preclude the use of negative values.
If you attempt to assign a negative value to an ushort, and expection would
be raised anyway, so you would have to test for it before assigning it or
you would need to handle the exception.

I think the only benefit from the unsigned value types were to save an
additional byte of data from the old black and white, no hard drive having,
we just got into outerspace so give us more time days.
"Mitchell S. Honnert" <ne**@REMhonnertOVE.com> wrote in message
news:uY**************@tk2msftngp13.phx.gbl... 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

[Mitchell S. Honnert]

> Do you need to support an unsigned value and force it as thus? Couldn't

you have the set modifier of a property enforce your desire to have
positive values? That's what I'm doing now. My intent, though, it so simplify things, both
for myself and for the user of my library.
Quote:

I wouldn't have to check for negative values; the data type itself would
simply preclude the use of negative values.
If you attempt to assign a negative value to an ushort, and expection
would be raised anyway, so you would have to test for it before assigning
it or you would need to handle the exception.

....where the "you" in your statement is the user of the library. As the
author or the library *I* wouldn't have to check the value. But this change
isn't about reducing my code. It's about improving the interface of the
library. Right now, the developer can see that the TrackNum is a Short.
They know that Short can accept negative values so might be tempted to set
the value to -1. It would only be when setting the TrackNum property that
they would get a specialized exception thrown in the Set section. But if
the TrackNum were a UShort, the user would automatically know from its type
that negative values are not allowed. I don't want to hide the validation
rules in the Set when they can just be an inherent property of the Property
(so to speak).

To me, changing the TrackNum to a UShort would be like placing a foreign key
on a table, whereas leaving it as a Short is like creating a database
trigger to check the relationship. One of my basic principles, both in
database design and application development, it to let the system do as much
of the checking as possible i.e. build the restriction into the system at
the most fundamental level possible. Using an unsigned type for variables
that I know will never be negative seeems to follow this principle. It's
just that I'm trying to reconcile this with the whole CLS-compliance issue.

- Mitchell S. Honnert

"AMDRIT" <am****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl... Do you need to support an unsigned value and force it as thus? Couldn't
you have the set modifier of a property enforce your desire to have
positive values?

Quote:

I wouldn't have to check for negative values; the data type itself would
simply preclude the use of negative values.

If you attempt to assign a negative value to an ushort, and expection
would be raised anyway, so you would have to test for it before assigning
it or you would need to handle the exception.

I think the only benefit from the unsigned value types were to save an
additional byte of data from the old black and white, no hard drive
having, we just got into outerspace so give us more time days.
"Mitchell S. Honnert" <ne**@REMhonnertOVE.com> wrote in message
news:uY**************@tk2msftngp13.phx.gbl...

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

[Herfried K. Wagner [MVP]]

"Mitchell S. Honnert" <ne**@REMhonnertOVE.com> schrieb:

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.

I suggest not to use unsigned types for this purpose. As you say correctly,
they are not CLS-compliant and thus should not be used in public interfaces.
If you take a look at the .NET Framework's class library, you will hardly
ever find the use of unsigned types in its publically accessible members.
However, use unsigned types inside your implementation if they directly map
to values in a file, for example.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[AMDRIT]

I assume you are doing this for shrink-wrap so the issue is not so trivial
for you as it would be for me. I would still go with either Int16 or Short
or Int32 and Integer accordingly. The thing is, your target audience is
VB.Net and C#, your dev platform is the same. The conversion doesn't seem
to be all that difficult for the other languages should they want to use
your product.

I had to do it all the time in the old VB days when working with windows
api. Large_Integer just didn't exist, ushort and ulong either. It is not
said to be an antagonist or to stick it to the "C" world, it is said out of
practicality of the situation and sensibility of what would be or not be
gained. I like it when the developers go that extra mile in the products
that I use and so I expect performance, informative feedback, and ease of
use. If that requires that I throw on a conversion here and there, it is
well worth it.

Just my two cents.

[Mitchell S. Honnert]

I'm very close to taking your advice, Herfried. But I guess I'm looking for
a more justification than "It's best practice." I too tend to look towards
the Framework itself as a guide for good design, but in this case I can't
help but think what I'm giving up outweighs adhering to a principle that
will affect a tiny fraction of the potential users of my library.

Let me put my question differently...

Since the biggest two CLS-compliant languages, VB.NET and C#, support
unsigned types, maybe it would be helpful to find out what languages I would
be excluding.

So, does anyone know which CLS languages *don't* support unsigned types?

Thanks,

Mitchell S. Honnert
www.UltraID3Lib.com
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:%2******************@TK2MSFTNGP15.phx.gbl...

"Mitchell S. Honnert" <ne**@REMhonnertOVE.com> schrieb:

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.

I suggest not to use unsigned types for this purpose. As you say
correctly, they are not CLS-compliant and thus should not be used in
public interfaces. If you take a look at the .NET Framework's class
library, you will hardly ever find the use of unsigned types in its
publically accessible members. However, use unsigned types inside your
implementation if they directly map to values in a file, for example.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>