Proposal to add typemapping to typescript binding

[Fred Shih]

Hello all,

I am working on b/40615900 to add typemapping for js/ts. The full proposal/design doc is here.

The tl;dr is as follows:

1. I propose we stick with the current C++ convention and add a ts_config section to the mojom build rule. There are some awkwardness around this due to language constraints, but I think it's better to stay consistent with what's already in place.

2. Typemapping will only be supported for ts. This is because the usage of closure is not strictly enforced in js. Type converters operating in an inherently sensitive part of the bindings library. Without a strong typing system, it can be very difficult to make any guarantees about the user supplied type converters.

3. We will generate a type converter interface. Users must implement this interface then reference it in their typemap. In the first iteration of the project, we will have two concepts: mojo type and mapped type. The converter will convert between the mojo type and the mapped type. The mojo type is abstracted away from user supplied converters through "data view" objects. The views are currently just a reference to the underlying mojo type, but it should reference the raw byte array in the future.

I'd like to eliminate the mojo type in future iterations of the project. This approach was chosen to keep the first iteration simpler and reduce risk.

A big callout is that migrating to mapped types for commonly used types (e.g.: url.mojom.Url) is going to be painful and can be error prone. Unfortunately we cannot rely on type checking in all instances, and migration need to be made within a single CL. At least, I can't think of a good way of doing partial migrations..

LMK if there are some thoughts around this. Thanks!

[Yuzhu Shen]

An idea: Given a type mojom.Foo, the set of Foo-referencing mojom definitions used by ts (note: no need to be all interfaces using mojom.Foo) are only or mostly used by ts itself and C++, then one possible way of doing partial migration:

1) temporarily introduce a duplicate mojom definition mojom.Foo2, which uses this new typemapping feature in ts (and it can map to the same C++ type as mojom.Foo, so at C++ side things stay the same).

2) gradually migrate mojom interfaces used by ts to use mojom.Foo2.

3) rename mojom.Foo2 back to mojom.Foo. This change should only (or mostly) affect mojom definitions and the typemappers.

 

LMK if there are some thoughts around this. Thanks!

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/5b600e30-05fa-4698-965c-e7ceed244eb6n%40chromium.org.