(Delphi-like) Limited-bounds-types?

  • Thread starter Thread starter matko
  • Start date Start date
M

matko

As far as I can see, there is no similar way of replicating the
following Delphi-code in C#... Is that true?

type
IntRange = -5..5;
CharRange = 'a'..'z';

TColors = (Red, White, Green, Blue, Yellow);
ColorRange = White..Blue;
 
matko,

No, there is not. In C# you would have to place explicit checks on your
methods/properties to validate that the values are in range.

However, this is not that difficult to do.

Hope this helps.
 
Hehe. Yes, I know it's not that difficult! ;)
It would, however, just be nice if there was a way...

Thanks for the reply!
matko,

No, there is not. In C# you would have to place explicit checks on your
methods/properties to validate that the values are in range.

However, this is not that difficult to do.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

matko said:
As far as I can see, there is no similar way of replicating the
following Delphi-code in C#... Is that true?

type
IntRange = -5..5;
CharRange = 'a'..'z';

TColors = (Red, White, Green, Blue, Yellow);
ColorRange = White..Blue;
Click to expand...
Click to expand...
 
matko said:
Hehe. Yes, I know it's not that difficult! ;)
It would, however, just be nice if there was a way...

Thanks for the reply!
Click to expand...

You may well be able to write a generic one in .NET 2.0, if that's any
help. I don't know that it would really be worth it though...

Jon
 
There is a way to do this in .NET 1.1 and before. You can create
context-bound objects which will allow you to intercept calls and perform
actions (you would indicate your range through attributes). However,
generally, this isn't something you want to do only because there is some
overhead in processing the call stack into a message based format (which is
what the context bound interception model does).
 
I don't know much about .NET 2.0 (yet), but couldn't you create an
IntRange struct in .NET 1.1 that would enforce a range? It wouldn't be
too difficult to do, and would incur minimum overhead.

The only downside is that you would have to declare a separate struct
for each base type, and define all of the implicit and explicit casts,
and math operators, etc, for the new struct.

Well... maybe I should qualify that "not too difficult to do": not too
hard on the brain, but lots of typing. :-)
 
Nicholas Paldino said:
There is a way to do this in .NET 1.1 and before. You can create
context-bound objects which will allow you to intercept calls and perform
actions (you would indicate your range through attributes). However,
generally, this isn't something you want to do only because there is some
overhead in processing the call stack into a message based format (which is
what the context bound interception model does).
Click to expand...

Well, you could do it in 1.1 without context-bound objects, by
converting the enum to its base type value and doing a range check on
that. It's just nicer with generics :)
 
Bruce Wood said:
I don't know much about .NET 2.0 (yet), but couldn't you create an
IntRange struct in .NET 1.1 that would enforce a range? It wouldn't be
too difficult to do, and would incur minimum overhead.

The only downside is that you would have to declare a separate struct
for each base type, and define all of the implicit and explicit casts,
and math operators, etc, for the new struct.

Well... maybe I should qualify that "not too difficult to do": not too
hard on the brain, but lots of typing. :-)
Click to expand...

Here's a .NET 2.0 version (and test case). The .NET 1.1 version would
either require boxing or a separate type for each enum etc:

using System;

public class Range<T> where T : struct, IComparable
{
T min, max;

public Range(T min, T max)
{
this.min = min;
this.max = max;
}

public bool Includes(T value)
{
return min.CompareTo(value) <= 0 &&
max.CompareTo(value) >= 0;
}
}

enum Foo
{
First,
Second,
Third,
Fourth,
Fifth
}

class Test
{
static void Main()
{
Range<Foo> range = new Range<Foo>(Foo.Second, Foo.Fourth);

foreach (Foo f in Enum.GetValues(typeof(Foo)))
{
Console.WriteLine ("{0} - {1}", f, range.Includes(f));
}
}
}
 
Matko,

You could handle these special cases in static methods of a class that is
named appropriately. For example, the enumeration could be handled like
this


public class MyColors
{
public enum TypeEnum : byte
{
Unknown = 0,
Red,
White,
Green,
Blue,
Yellow
};

public static bool IsColorInTheFlag(TypeEnum eColor)
{
switch(eColor)
{
case TypeEnum.Red :
case TypeEnum.White:
case TypeEnum.Blue:
return true;
default :
return false;
}
}

public static bool IsValidColor(byte clr)
{
return ((clr > 0) && Enum.IsDefined(typeof(MyColors.TypeEnum), clr));
}

}

Dave
 
Generics doesn't really do much here (yes, compile time checking against
the type passed in is nice), but I think that the thing the OP is trying to
get at is that he doesn't want to perform a check manually, he wants to say
somehow that this is his range, and have the runtime enforce it.
 
Nicholas Paldino said:
Generics doesn't really do much here (yes, compile time checking against
the type passed in is nice)
Click to expand...

It also prevents boxing.
but I think that the thing the OP is trying to
get at is that he doesn't want to perform a check manually, he wants to say
somehow that this is his range, and have the runtime enforce it.
Click to expand...

Well, I'm not sure I see much difference between:

ColorRange = White..Blue;
and
Range<Color> colorRange = new Range<Color>(Color.White, Color.Blue);

(I'd have expected new Range(Color.White, Color.Blue) to work, but it
doesn't - I need to check the spec to see why.)

The former is certainly neater, but you still get to find out
inclusivity etc - and it probably wouldn't be too hard to give it a bit
more functionality if required.

Maybe I'm missing some more functionality - but all the examples given
can be done with the Range type I gave.
 
Jon,

I'm not an expert on Delphi, but my impression is that the OP wanted
something more. Yes, the range class does work, but that's not the point.

With context bound objects, you can do something like:

public void MyFunction([Range(0, 5)] int value)
{
// Do something with value here.
// NO need to check against range, since it will have
// already been checked by the context bound object.
}

This is a ficticuous context bound attribute, used to display the point.
This way, his function can assume the check passed, otherwise, the
interception code which the Range attribute handles would throw an
exception.
 
PRECISELY!

Wouldn't it be nice to have such (easily applicable) functionality in
C#?
Jon,

I'm not an expert on Delphi, but my impression is that the OP wanted
something more. Yes, the range class does work, but that's not the point.

With context bound objects, you can do something like:

public void MyFunction([Range(0, 5)] int value)
{
// Do something with value here.
// NO need to check against range, since it will have
// already been checked by the context bound object.
}

This is a ficticuous context bound attribute, used to display the point.
This way, his function can assume the check passed, otherwise, the
interception code which the Range attribute handles would throw an
exception.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Jon Skeet said:
It also prevents boxing.


Well, I'm not sure I see much difference between:

ColorRange = White..Blue;
and
Range<Color> colorRange = new Range<Color>(Color.White, Color.Blue);

(I'd have expected new Range(Color.White, Color.Blue) to work, but it
doesn't - I need to check the spec to see why.)

The former is certainly neater, but you still get to find out
inclusivity etc - and it probably wouldn't be too hard to give it a bit
more functionality if required.

Maybe I'm missing some more functionality - but all the examples given
can be done with the Range type I gave.
Click to expand...
Click to expand...
 
matko,

Unfortunately, you would have to do something with ContextBoundObjects
in order to do this. It will hinder performance, so it is not a feasibile
solution for this kind of thing (since it would be done so often).

However, if you want more information on this, check out the following
MSDN magazine article:

http://msdn.microsoft.com/msdnmag/issues/03/03/ContextsinNET/


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

matko said:
PRECISELY!

Wouldn't it be nice to have such (easily applicable) functionality in
C#?
Jon,

I'm not an expert on Delphi, but my impression is that the OP wanted
something more. Yes, the range class does work, but that's not the
point.

With context bound objects, you can do something like:

public void MyFunction([Range(0, 5)] int value)
{
// Do something with value here.
// NO need to check against range, since it will have
// already been checked by the context bound object.
}

This is a ficticuous context bound attribute, used to display the
point.
This way, his function can assume the check passed, otherwise, the
interception code which the Range attribute handles would throw an
exception.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Jon Skeet said:
Generics doesn't really do much here (yes, compile time checking
against
the type passed in is nice)

It also prevents boxing.

but I think that the thing the OP is trying to
get at is that he doesn't want to perform a check manually, he wants
to
say
somehow that this is his range, and have the runtime enforce it.

Well, I'm not sure I see much difference between:

ColorRange = White..Blue;
and
Range<Color> colorRange = new Range<Color>(Color.White, Color.Blue);

(I'd have expected new Range(Color.White, Color.Blue) to work, but it
doesn't - I need to check the spec to see why.)

The former is certainly neater, but you still get to find out
inclusivity etc - and it probably wouldn't be too hard to give it a bit
more functionality if required.

Maybe I'm missing some more functionality - but all the examples given
can be done with the Range type I gave.
Click to expand...
Click to expand...
Click to expand...
 
Bingo!

I want the compiler or/and the runtime-environment to detect
bounds-related errors.
That such (limited-bounds) type declaration is allowed in Delphi is
very... pleasant!
Generics doesn't really do much here (yes, compile time checking against
the type passed in is nice), but I think that the thing the OP is trying to
get at is that he doesn't want to perform a check manually, he wants to say
somehow that this is his range, and have the runtime enforce it.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Jon Skeet said:
Here's a .NET 2.0 version (and test case). The .NET 1.1 version would
either require boxing or a separate type for each enum etc:

using System;

public class Range<T> where T : struct, IComparable
{
T min, max;

public Range(T min, T max)
{
this.min = min;
this.max = max;
}

public bool Includes(T value)
{
return min.CompareTo(value) <= 0 &&
max.CompareTo(value) >= 0;
}
}

enum Foo
{
First,
Second,
Third,
Fourth,
Fifth
}

class Test
{
static void Main()
{
Range<Foo> range = new Range<Foo>(Foo.Second, Foo.Fourth);

foreach (Foo f in Enum.GetValues(typeof(Foo)))
{
Console.WriteLine ("{0} - {1}", f, range.Includes(f));
}
}
}
Click to expand...
Click to expand...
 
Nicholas Paldino said:
Jon,

I'm not an expert on Delphi, but my impression is that the OP wanted
something more. Yes, the range class does work, but that's not the point.

With context bound objects, you can do something like:

public void MyFunction([Range(0, 5)] int value)
{
// Do something with value here.
// NO need to check against range, since it will have
// already been checked by the context bound object.
}

This is a ficticuous context bound attribute, used to display the point.
This way, his function can assume the check passed, otherwise, the
interception code which the Range attribute handles would throw an
exception.
Click to expand...

Ah, right, I'm with you. Yes, that would be handy. There are lots of
things like that which sometimes are part of design-by-contract,
sometimes part of AOP etc. Hopefully Anders is looking into those for
C# 4.0...
 
Not from what I have seen. Anders is NOT a big fan of AOP in the least.
Method interception - MAYBE, but AOP, definitely not.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Jon Skeet said:
Nicholas Paldino said:
Jon,

I'm not an expert on Delphi, but my impression is that the OP wanted
something more. Yes, the range class does work, but that's not the
point.

With context bound objects, you can do something like:

public void MyFunction([Range(0, 5)] int value)
{
// Do something with value here.
// NO need to check against range, since it will have
// already been checked by the context bound object.
}

This is a ficticuous context bound attribute, used to display the
point.
This way, his function can assume the check passed, otherwise, the
interception code which the Range attribute handles would throw an
exception.
Click to expand...

Ah, right, I'm with you. Yes, that would be handy. There are lots of
things like that which sometimes are part of design-by-contract,
sometimes part of AOP etc. Hopefully Anders is looking into those for
C# 4.0...
Click to expand...
 
Nicholas Paldino said:
Not from what I have seen. Anders is NOT a big fan of AOP in the least.
Method interception - MAYBE, but AOP, definitely not.
Click to expand...

Well, that might be due to current implementations, limitations etc. I
suspect he can see the benefits of being able to specify cross-cutting
concerns, etc, even if he's not happy with how it's all done at the
moment.

I wouldn't be surprised if something came out which at least tackled
the same kinds of issues that AOP does, even if it's not immediately
recognisable as an AOP implementation.
 
Well, as I pointed out you _could_ create a struct to wrap another
value type and then have that struct do the bounds checking on every
assignment, because each assignment from a base type would really be an
implicit conversion operation. It would invovle significant overhead
(every assignment would really be a method call), and it would also be
a heck of a lot of code to write, as you would have to reproduce every
operator, including all implicit and explicit conversions, of the
native type in your struct wrapper.

This isn't just a Delphi thing. I remember this back in 1980 with
Pascal, so it's not as though it's some fancy new AOP-related thing.
It's probably just another of those features that Anders and the C#
team saw as offering some benefits, but not sufficient benefit to
justify adding yet more syntax to the language.

You could ask for the feature, anyway... it's been in enough other
languages (Pascal and now Delphi) that it's obviously not some flash in
the pan.
 
Oh, sure.
Delphi _is_, more-or-less (more more than less), Pascal.

Anyway, I'd love this to be a part of C#. It's neat and helpful
functionality.

Thanks for all comments ;)
 
Back
Top