Date and time and Ice

[callan]

Hiya all.

We're currently in the midst of our Ice implementation which is designed to offer a variety of language bindings (C#, Java, C++ and Python) to client developers.

As Ice is a cross-language technology it has (at least to my knowledge ) no built-in, cross-language way of handling date and time that maps directly to class-library types (System.DateTime or System.TimeSpan in C# for instance), nor do we expect it to. We are quite happy to roll our own solution to the problem, however before we do I was wondering if there is any community accepted paradigm or experience we should know about.

Thanks.

Ciao.

[stephan]

I am using this code:

module global
{
	struct DateTime
	{
		int nYear;
		byte nMonth;
		byte nDay;
		byte nHour;
		byte nMinute;
		byte nSecond;
	};
	
	sequence<DateTime> DateTimeList;
	
	enum WeekDays {Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday};

	sequence<WeekDays> WeekDayList;

	struct Date
	{
		int nYear;
		byte nMonth;
		byte nDay;
	};

	struct Time
	{
		byte nHour;
		byte nMinute;
		byte nSecond;
	};

...
};

in all my projects and have a utils.cpp, utils.cs, utils.py to convert date time values from the respective language representation (QDateTime, System.DateTime and the likes).

No rocket science at all, but it works well.

regs,

Stephan

[michi]

If you need times, I would create appropriate Slice definitions as suggested in the previous post. It's not really the job of middleware to offer types that don't have reasonable representations in the majority of target languages.

And, once we open this particular can of worms, where would we stop? People quite legitimately might want types to represent temperatures, email addresses, URLs, and a whole raft of other things. None of these are unreasonable, but none of these are the job of the middleware. For one, it is difficult to develop a date/time class and to implement it in Java, C++, C#, VB, PHP, and Python and, at the same time, guarantee that the implementation has identical semantics on all platforms (which is necessary for interoperability). Also, adding such application-specific types would violate the "keep it simple" principle: application developers would have to learn ZeroC's implementation of these types, but could not exchange them with third-party libraries. And, finally, our users would end up with a run time that is bloated because many applications would never use these additional types.

Cheers,

Michi.

[stephan]

Just a quick thought... How about creating a section on your website with some non-maintained or semi-maintained code? If you take a look at e.g. the website of Trolltech, they have something called Qt Solutions. Something that would make the core distribution unnecessarily bigger but something that's nice to have anyway. Such a section would be a nice place for some date time representation including language-specific conversion, for the evictor class which is almost hidden in your distribution somewhere in the demo path.

Is there any interest in the community for such a place? And some code to share at all?

regs,

Stephan

[callan]

@Michi:
100% agreed. It is not the job of cross-language middleware to provide infrastructure to serialize dates, times, URLs, e-mail addresses, etc. from language to language out of the box. As I said, we are not expecting Ice to do this for us.

We have many (Java in particular) class-library types that we cannot directly serialize ("java.util.Set" or nullable types for instance) because of a lack of class-library or language parallels in something like C# (leaving out the latest versions of .NET 2.0 of course ). We do not expect Ice to solve these problems for us either; providing a cross-language solution does create its fair share of work and we're keenly aware of it.

As an aside: does ZeroC have plans to introduce nullable types into the Slice language?

@Stephan:
I like your concept, I have been thinking about a similar Slice definition and utility types in each language. I'd certainly be happy to host and/or release what our project comes up with for the Slice definition along with the utility classes for each language. Using a BSD license most likely.

If ZeroC wants to provide a "contrib" section somewhere I'd certainly be willing to submit code and I'd expect the usual support disclaimer to apply.

[michi]

Originally Posted by stephan

Just a quick thought... How about creating a section on your website with some non-maintained or semi-maintained code?

That sounds like a nice idea. We'll have a look at adding a section to our web site for contributions. To add something, the easiest thing is probably for you to mail us the contribution, and we'll add it to the web site.

Cheers,

Michi.

[michi]

Originally Posted by callan

@Michi:As an aside: does ZeroC have plans to introduce nullable types into the Slice language?

I think it unlikely at this point. The main issue I see is that most languages do not have a native representation for nullable types. In effect, we would end up creating something like a struct or class containing a boolean and a value, plus a few accessors, such as hasValue(). But doing this then creates yet another custom type that users would have to learn, and that could not easily be exchanged with third-party libraries.

I'm also not convinced that nullable types are all that useful. They are mostly syntactic sugar and, considering that they do not add all that much functionality, it seems questionable whether they deserve to be treated as a first-class language concept.

With Ice, the easiest way to create a nullable type is to either make a struct containing a boolean and the value, or possibly do something like the following:

// Slice
interface NullableBase
{
    bool hasValue();
    void setToNull();
};

exception ValueIsNull {};

class NullableInt implements NullableBase
{
    int getValue() throws ValueIsNull;
    void setValue();
};

Cheers,

Michi.