ext/intl: Add IntlDatePatternGenerator skeleton methods

[LamentXU123]

This add missing Skeleton functions similar to #23049 and #23017 for IntlDatePatternGenerator. This adds IntlDatePatternGenerator::getSkeleton() and IntlDatePatternGenerator::getBaseSkeleton()

• DateTimePatternGenerator::getSkeleton()
  https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/classicu_1_1DateTimePatternGenerator.html#ac27933661baec901aaf690b4e6db9159

• DateTimePatternGenerator::getBaseSkeleton()
  https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/classicu_1_1DateTimePatternGenerator.html#ae635530015fcad95a1bae9123b2f79f6

[devnexen]

per icu headers

* getSkeleton() works exactly like staticGetSkeleton().
* Use staticGetSkeleton() instead of getSkeleton().

[devnexen]

Thus, since the output wouldn't depend on the generator's locale, the constructor is more a "gimmick" than actually meaningful. wdyt ?

[LamentXU123]

per icu headers

* getSkeleton() works exactly like staticGetSkeleton().
* Use staticGetSkeleton() instead of getSkeleton().

I saw this line ofc. I made the decision to use this because this is a directly exposure and using staticGetSkeleton might confuse people when reading this line (why not use ICU's getSkeleton in the getSkeleton() implementation)

per source:

void DateTimePatternGenerator::GetSkeleton(UnicodeString &buffer) const {
    staticGetSkeleton(this, buffer);
}

void DateTimePatternGenerator::staticGetSkeleton(const DecimalFormat *df, UnicodeString &buffer) {
    buffer.clear();
     balabalabala....
}

They are literally the same. wdyt?

(I think the the reason why the documentation recommend people to use the static version is because GetSkeleton is a virtual instance member method of DateTimePatternGenerator. However, since we are just exposing it to PHP userland I don't think we need to take this into consideration)

[LamentXU123]

Ok I see the reason to use the static version. Ignore my comment above

[devnexen]

Yes, neither overload touches PHP's "this" at all, which proves your locale point. The generator instance only carries the error state, so constructing one loads locale data for nothing.

[devnexen]

note: I hope you do not have too much to "cram" before the feature freeze btw ?

[LamentXU123]

Thus, since the output wouldn't depend on the generator's locale, the constructor is more a "gimmick" than actually meaningful. wdyt ?

This is indeed a good suggestion. In this case they should be static methods.

note: I hope you do not have too much to "cram" before the feature freeze btw ?

I won't :) This just happens to came across my mind when I am reviewing your SpoofChecker PR yesterday.

Yes, neither overload touches PHP's "this" at all, which proves your locale point. The generator instance only carries the error state, so constructing one loads locale data for nothing.

Exactly.

[devnexen]

Having a case that uses this pattern would be nice

$patterns = [
    "'at' HH:mm",
    "y年M月d日",
    "yyyy-MM-dd",
    "MMMMM",
    "MMM",
    "HH:mm:ss zzz dd/MM/y",
    "'at HH:mm",
];
foreach ($patterns as $p) {
    printf("%-22s %-12s %s\n", $p,
        IntlDatePatternGenerator::getSkeleton($p),
        IntlDatePatternGenerator::getBaseSkeleton($p));
}

[devnexen]

nit: we re not constrained by C limitations we can do here like has been done for spoofchecker earlier:

template <typename F>
static void dtpg_get_skeleton(INTERNAL_FUNCTION_PARAMETERS, F&& skeletonfn, const char *errmsg)...

[LamentXU123]

I personally dont like template syntax. But its fine anyways.

[devnexen]

understandable, albeit template usage here is very basic I do not think we would need to go much further anytime soon.

[devnexen]

lgtm