Go runtime type registration #2561
Assignees
Labels
effort/small
Small work item – less than a day of effort
feature-request
A feature should be added or improved.
language/go
Regarding GoLang bindings
module/runtime
Issues affecting the `jsii-runtime`
Milestone
Comments
This was referenced Feb 11, 2021
RomainMuller
added a commit
that referenced
this issue
Feb 12, 2021
The previous convention of passing of `implementationMap` values at the
call sites for value-returning calls (`Get`, `Invoke`, and their static
counterparts) did not provide sufficient information to properly convert
certain values (JavaScript returning a descendant of the declared return
type, decoding enum members, ability to represent values that implement
multiple interfaces in JavaScript, ...).
In order to address this shortcomings, this mechanism was replaced with
a new `func init(){}` block emitted in each package, which is
responsible for registering the generated types with the runtime
library. This allows the `client` to determine the correct go type to
use when converting arbitrary values returned from JavaScript, as it has
visibility on the complete set of available types, by fully qualified
name.
This minimally changes the conversion of JavaScript values into go
values, so as to minimize the footprit of this change. Of course,
subsequent effort will be made to fully leverage the potential of the
extended information (i.e: correctly processing enum members, ...).
Fixes #2561
RomainMuller
added a commit
that referenced
this issue
Feb 12, 2021
The previous convention of passing of `implementationMap` values at the
call sites for value-returning calls (`Get`, `Invoke`, and their static
counterparts) did not provide sufficient information to properly convert
certain values (JavaScript returning a descendant of the declared return
type, decoding enum members, ability to represent values that implement
multiple interfaces in JavaScript, ...).
In order to address this shortcomings, this mechanism was replaced with
a new `func init(){}` block emitted in each package, which is
responsible for registering the generated types with the runtime
library. This allows the `client` to determine the correct go type to
use when converting arbitrary values returned from JavaScript, as it has
visibility on the complete set of available types, by fully qualified
name.
This minimally changes the conversion of JavaScript values into go
values, so as to minimize the footprit of this change. Of course,
subsequent effort will be made to fully leverage the potential of the
extended information (i.e: correctly processing enum members, ...).
Fixes #2561
mergify bot
pushed a commit
that referenced
this issue
Feb 17, 2021
The previous convention of passing of `implementationMap` values at the
call sites for value-returning calls (`Get`, `Invoke`, and their static
counterparts) did not provide sufficient information to properly convert
certain values (JavaScript returning a descendant of the declared return
type, decoding enum members, ability to represent values that implement
multiple interfaces in JavaScript, ...).
In order to address this shortcomings, this mechanism was replaced with
a new `func init(){}` block emitted in each package, which is
responsible for registering the generated types with the runtime
library. This allows the `client` to determine the correct go type to
use when converting arbitrary values returned from JavaScript, as it has
visibility on the complete set of available types, by fully qualified
name.
This minimally changes the conversion of JavaScript values into go
values, so as to minimize the footprit of this change. Of course,
subsequent effort will be made to fully leverage the potential of the
extended information (i.e: correctly processing enum members, ...).
Fixes #2561
---
By submitting this pull request, I confirm that my contribution is made under the terms of the [Apache 2.0 license].
[Apache 2.0 license]: https://www.apache.org/licenses/LICENSE-2.0
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
🚀 Feature Request
We need to re-work the type handling, moving way from the
impMappassed to the runtimesInvoke,StaticInvoke,GetandStaticGetcalls, and instead have a client-wide type registry.This is necessary to enable returning the correct dynamic type in several occasions:
ParentClass, dynamic value isChildClass extends ParentClassThis may also be necessary to be able to correctly handle enum values; and to be able to re-hydrate structs correctly.
The text was updated successfully, but these errors were encountered: