Conversion between IntPoint/DoublePoint and .net Point/PointF about aforge

[GoogleCodeExporter]

Unfortunately, converting from double (DoublePoint) to float (PointF) is a 
information-losing conversion, and Microsoft's guidelines say that should not 
be done automatically.
Similarly, the removal of IntPoint and DoublePoint would be a breaking change, 
which should be done carefully, if at all.

Language-lawyer tendencies assuaged, I'd vote for breaking changes over 
automatic conversions between various functionally equivalent structures. 
Failing that, I'd also vote for truncating doubles to floats automatically.

If you (AForge devs) are opposed to such things, extension methods to convert 
IEnumerable<IntPoint> to IEnumerable<Point> and IEnumerable<DoublePoint> to 
IEnumerable<PointF> would make the array/list of points issue less problematic; 
it's easy enough to take an IEnumberable and convert it to the desired concrete 
class. Or to just use it as an IEnumerable.

Original comment by [email protected] on 12 Oct 2010 at 4:09

[GoogleCodeExporter]

I really agree that the fact AForge.NET framework has its own IntPoint and 
DoublePoint structures may look awkward and introduce pain. I can explain why 
they came ...

I simple don’t get why MS decided to put Point and PointF into 
Systtem.Drawing namespace.  Why should I reference this assembly and use this 
namespace if don’t want to draw at all? What if I want to create some 
math/geometry/whatever routines, which deal with points, but not with drawing?

Well, maybe the above though is not an excuse to introduce such awkwardness, 
but putting point structures into System.Drawing is not the best idea either.

Original comment by [email protected] on 10 Nov 2010 at 10:51

[GoogleCodeExporter]

The reasoning behinds the decision to provide custom point structures outside 
System.Drawing makes sense. However, I think it would be useful to provide more 
of the methods implemented by System.Drawining.Point/PointF, in particular the 
Empty property to return a zero-valued point, and methods for truncating, 
ceiling and flooring a Point/DoublePoint. They could be marked as 
[Serializable] as well.

By the way, wouldn't it be better if X and Y were exposed as properties instead 
of public fields? Those would be optimized by the compiler anyway.

Original comment by [email protected] on 14 Apr 2011 at 2:20

[GoogleCodeExporter]

>> However, I think it would be useful to provide more of the methods 
implemented
>> by System.Drawining.Point/PointF, in particular the Empty property to return
>> a zero-valued point, and methods for truncating, ceiling and flooring a
>> Point/DoublePoint.
Yep, could be done. You can even submit a patch for this ;)

>> By the way, wouldn't it be better if X and Y were exposed as properties
>> instead of public fields?
We may do it. However the benefit is not that obvious in this particular case. 
Cannot imagine any type of extra code someday appearing in setter. (Take a look 
at XNA code - MS does not bother to create extra properties for simple 
structures like Vector3)

>> Those would be optimized by the compiler anyway.
Only JIT compiler may do it.

Original comment by [email protected] on 17 Apr 2011 at 9:54