[Development] Calendar Systems proposal

[Edward Welbourne]

I had remarked:
>> That shall complement Soroush Rabiei's work on the C++ side:
Hamed Masafi (30 January 2017 21:07) replied:
> Yes, that's right. I'm trying to port Soroush's calendar mechanism to
> qml side of Qt.

Good.

>> If I understand Lars correctly, he prefers an API where the calendar
>> object carries methods that act on a date and any further arguments
>> it may need (similar to QLocale), so cal.toString(date, "yyyy-MM-dd")
>> is more likely (although I personally like the style of API you give
>> above, where the date object has the calendar-aware methods; too many
>> of the details are the same between calendar systems).  Aside from
>> that, this is roughly the shape the C++ API shall have, making it a
>> natural model for the QML to follow.

> I'm not sure we can add an global type to script engine that are not
> in ecma script.

>From what I've now understood of ECMA-402, we can do much of this via
the Date.toLocaleString() family of APIs, without non-ECMA types in our
engine.  It remains that we have a Qt object to which we can reasonably
add things for use by QML - if we feel the need for it.

>> Not sure what you're proposing here - you don't mention Qt.calendar
>> in the code example, which looks more like 1) with JalaliCalendar
>> moved to the Qt object - which may indeed be a better place for it
>> than as a naked global object.

> No; in this case Qt.JalaliCalendar is a QEnum and not an object (my
> suggestion explained below)

As explained elsewhere, I prefer an instance-based calendar system over
an enum-based one *in C++*.  However, from V4's perspective, that shall
all be hidden inside QML's implementation and we'll most likely access
it via names.  An instance-based model can handle that by providing some
way for the classes defining the instances we use in C++ to also tell
the QML engine to associate them with a suitable name, e.g. 'Jalali',
possibly with an alias mechanism - since Date.toLocaleString needs us to
also recognise 'Persian' as referring to that.

>> I don't know what rules QML might impose.  Each of these would, in
>> one way or another, require the calendar system code to register
>> itself in some way with QML, associated with the name by which QML is
>> to refer to it.  The details of whether that name is in the namespace
>> of some visible object (the ECMAScript global object or the Qt
>> object) or in some internal mapping (for 2) are a matter of what's
>> practical or convenient - someone with more QML fu than I can claim
>> can advise you better there.

> My prefer option is form (3)
> We can add an enumeration to global space.
> var date = new Date;
> var out = date.toString(Qt.JalaliCalendar, "yyyy-MM-dd");

At the level of QML, this works fine; it's just another binding of a
string to the underlying implementation of the calendar system.  We
shall need toLocale(|Date|Time)String(locale, options) to also know a
binding to the u-ca-* fragments in locale.

However, adapting the ECMA-262 Date.toString() to take such an enum
would present compatibility problems; better to handle this within the
ECMA-402 locale framework, as discussed earlier.

> I think to continue we must conclusion on that calendar types must be
> plugin or not?

As discussed in my last mail, we don't need to actually do a plugin
approach; the instance-based approach of Souroush's present work is just
fine.  Because third parties can sub-class QAbstractCalendar, they can
do their own crazy things with plugins if they want, but we don't need
to care about that.  In QML, we can provide enum-like access to the
calendar systems where we see a use for it; and we'll definitely need a
string-based access in order to support date.toLocaleString() and its
peers properly.

	Eddy.