When I first was going about trying to wrangle the ODBC extension to work in Ren-C, it had some C time and date structures that would come back from the database. These are DATE_STRUCT, TIME_STRUCT, and TIMESTAMP_STRUCT. Those have to be turned into TIME! and DATE! values.
But there were no functions in the API yet for making TIME! and DATE! values.
Well, there was rebInteger() for taking a C integer and making an INTEGER!. So to move things along, I went ahead and made functions for taking multiple C integers and making times and dates:
REBVAL *time = rebTimeHMS(hour, minute, second); REBVAL *date = rebDateYMD(year, month, day); REBVAL *datetime = rebDateTime(date, time);
But the API vision has established clarity about being of limited entry points. So rather than keep cooking up new C functions taking C arguments, it's better to build on a more limited facility and call Rebol code!
REBVAL *time = rebValue("make time! [", rebI(hour), rebI(minute), rebI(second), "]"); REBVAL *date = rebValue("make date! [", rebI(day), rebI(month), rebI(year), "]"); REBVAL *datetime = rebValue("use [date] [", "date:", date, "date/time:", time, "]");
That third one is a little weird, and anyone who wants to suggest a better way of doing it can chime in on issue #2313. But the point is to keep pushing on Rebol the language, not chasing down an infinitely long cascade of API entry points.
I'm feeling really good about it. Though I will re-iterate that it does bring up all those questions of where this stuff is getting bound. You don't want some extension deciding to redefine MAKE, or TIME!, and incidentally wind up breaking the ODBC module's expectations. There has to be some isolation, very much similar to how modules will be isolated...except (somehow) applying to the C code.
But that's the vision, and if you haven't been reading the interesting usages like in the ZeroMQ extension, please do! Would be good to hear any thoughts people are having, while watching it materialize...