DbDate enhancements

[wriedmann]

Hi Robert,
would it be possible to add operator methods to the DbDate structure?

Code: Select all

structure DbDate implements IDate
	property Year		as int auto get private set
	property Month		as int auto get private set
	property Day		as int auto get private set
	property @@Value		as DateTime get DateTime{Year, Month, Day}
	property IsEmpty	as logic get Month == 0
	constructor(nYear as int, nMonth as int, nDay as int)
		Year	:= nYear
		Month   := nMonth
		Day     := nDay
		return
	override method ToString() as string
        if IsEmpty
            return "    -  -  "
        endif
        return self:Value:ToString("yyyy-MM-dd")

public static operator >( oDate1 as DbDate, oDate2 as DbDate ) as logic

	return oDate1:Value > oDate2:Value


public static operator <( oDate1 as DbDate, oDate2 as DbDate ) as logic

	return oDate1:Value < oDate2:Value

public static operator <=( oDate1 as DbDate, oDate2 as DbDate ) as logic

	return oDate1:Value <= oDate2:Value

public static operator >=( oDate1 as DbDate, oDate2 as DbDate ) as logic

	return oDate1:Value >= oDate2:Value

public static operator !=( oDate1 as DbDate, oDate2 as DbDate ) as logic

	return oDate1:Value != oDate2:Value

public static operator ==( oDate1 as DbDate, oDate2 as DbDate ) as logic

	return oDate1:Value == oDate2:Value

static method Compare( oDate1 as DbDate, oDate2 as DbDate ) as int

	return System.DateTime.Compare( oDate1:Value, oDate2:Value )

override method GetHashCode() as int

	return self:GetHashCode()

end structure

That would it make easier to work with the RDD object, for Core code that uses DBF files

Wolfgang

[robert]

Wolfgang,

The DbDate type is added to have a light weight type that implements the IDate() interface, so we don't have to move __Date to the Core assembly.
I think we can add these operators, but that sort of defeats the idea of DbDate.
OTOH moving __Date to XSharp.Core will not work because it has operators with USUAL parameters.
Adding these operators means that we add support for IComparable<DbDate> and IComparable
I'll discuss this internally but I think this would be possible.

Robert

[wriedmann]

Hi Robert,
as you know I'm trying to work with the Core dialect whenever possible, but sometimes (often....) I need to access DBF data, using my strong typed CoreDBF class I had posted earlier here (maybe it could be an idea to add that class also to the runtime?).
And the CoreDB classes return an DbDate structure when reading a date field.
So if we could use this datatype as a normal datatype it would make the life easier.
Wolfgang
P.S. I think also about C#/VB.NET applications that could use the X# RDD this manner in an entirely object oriented way

[Chris]

Hi Wolfgang,

May I ask why don't you like using simply for example oDbDate1:Value <= DbDate2:Value ?

This would keep things simple and make your code to depend less on any changes we may need to make in the type in the future.

[wriedmann]

Hi Chris,
it is simply easier to write and to read....
Wolfgang

[Chris]

Hi Wolfgang,

I understand, but if we do this, then what's next? Shouldn't then we also support subtracting DbDate objects? Also adding/subtracting numbers to it? Etc... In short everything that the underlying DateTime class supports as well? And as Robert noted internally, thendo the same thing for DbFloat and support everything the underlying System.Double type supports?

In my opinion, it is much cleaner to keep things as is and do operations directly on the underlying type of those objects, instead of re-implementing everything. But if you do insist, it indeed shouln't be difficult to implement this.

[wriedmann]

Hi Chris,
I'm simply thinking a step further: in future applications you will need to access legacy and DBF data with other languages, like C# and VB.NET (and X# Core of course).
Therefore I have written a simple and thin object oriented layer over the RDD system.
The RDD system returns some datatypes. The most important ones like string and logic are covered by the .NET Framework.
But some of them are not covered, like DbDate and DbFloat.
Maybe it could be a better option to transform them in the access layer to DateTime and Decimal, respectively.
For Decimal I see non problem because there is no loss of information.
For DateTime there could be a problem since writing a DateTime value to a Date field looses the time information.
And then: VFP has a DateTime data type. That could also conflict.
Wolfgang
P.S. IMHO there should be an option in the RDD system to return a Decimal instead of a DbFloat value.

[Chris]

Hi Wolfgang,

I agree, it would be best if possible to return native data types. But I think not just replicating everything the native type has into the intermediate type. About DbFloat/IFloat, actually the important thing about it is the formatting info about how many decimal digits should be visible, and this information is not available in neither System.Double or System.Decimal.

[wriedmann]

Hi Chris,
it may sound strange, but when working on business applications, sometimes I'm missing the Cobol numeric datatypes...
But at least System.Decimal has not the problems we always encounter with the float datatype in VO.
Wolfgang