Ecma402 traits #125
Ecma402 traits #125
Conversation
filmil
force-pushed
the
ecma402-traits
branch
5 times, most recently
from
764bcb4
to
0cf05ec
Compare
|
@zbraniecki if you take a look, feel free to ignore the |
|
An amusing bit is that the implementation revealed a few practical issues that So, a few conditional compilation experiments later, there's something that works on ICU 67, and gives suboptimal but still useful results on ICU 66 and lower. |
| use ecma402_traits::listformat::options; | ||
|
|
||
| // Converts the param types from ECMA-402 into ICU. | ||
| pub fn to_icu_width(style: &options::Style) -> usys::UListFormatterWidth { |
There was a problem hiding this comment.
I'm conflicted. If we're making rust_icu depend on ecma402_traits anyway, maybe we should add standard From/To conversion traits to rust_icu. (This would require some hacks for bindgen code; cf. rust-lang/rust-bindgen#1089.)
There was a problem hiding this comment.
(This would be in a later CL, of course.)
There was a problem hiding this comment.
Not sure how automated bindgen would help in this case though, care to elaborate?
But I share your concern -- it reads like an inverted dependency on (fairly low level) rust_icu that it should conform to a set of high level conceptual APIs (ecma 402).
On the other hand, reimplementing Locale in a rust_icu backed implementation of ecma402 seems like we're, well, redoing the work that already exists in rust_icu.
|
On Fri, Jun 12, 2020 at 1:04 PM Konstantin Pozin ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In rust_icu_ecma402/src/lib.rs
<#125 (comment)>:
+// The list formatter uses features that are not available in ICU versions prior
+// to 67.
So do we want this information to be visible somewhere? Using //! as a
module comment, or in the README?
Yes, we have to document it as it affects the functionality. I'll make
sure that the quirk is documented well for users that don't want or need to
dive into the code. The current code, however, shows very clearly what
happens in the two cases; but you'd still need to dive in to see it.
Hence, docs needed.
F
… |
The motivation is that the proposals are not experimental *code*, but rather, they are documents that are meant to be read, and happen to have some bits that you can copy over to the rust playground. So in that respect, the texts are no different than any other doc you may write, hence the move to proposals.
This change contributes an implementation of the [Intl.ListFormat API][lfapi], as prescribed by [ECMA-402][ecma]. The ECMA-402 API surface is developed in lock-step with a `rust_icu` backed implementation. The approach is documented [here][appr]. [lfapi]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/ListFormat [ecma]: https://www.ecma-international.org/publications/standards/Ecma-402.htm [appr]: https://raw.githubusercontent.com/google/rust_icu/master/experimental/ecma402_listformat/src/lib.rs See issue google#125
This change contributes an implementation of the [Intl.ListFormat API][lfapi], as prescribed by [ECMA-402][ecma]. The ECMA-402 API surface is developed in lock-step with a `rust_icu` backed implementation. The approach is documented [here][appr]. [lfapi]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/ListFormat [ecma]: https://www.ecma-international.org/publications/standards/Ecma-402.htm [appr]: https://raw.githubusercontent.com/google/rust_icu/master/experimental/ecma402_listformat/src/lib.rs See issue google#125
Here is a draft implementation of ECMA 402 API surface that was proposed here: https://github.com/google/rust_icu/blob/master/experimental/ecma402_listformat/src/lib.rs
Before I equip it with better docs and README content, initial thoughts from y'all would be welcome.
@kpozin
ulocnow depends on theecma402_traits, which means we need to import it in Fuchsia too. It seemed that if I created a new aliased type for the locale, we'd not get much in return except we'd get the decoupling.