@jsii/kernel 1.125.0 → 1.126.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/lib/kernel.js +53 -5
- package/package.json +5 -5
package/lib/kernel.js
CHANGED
|
@@ -679,12 +679,60 @@ _Kernel_assemblies = new WeakMap(), _Kernel_objects = new WeakMap(), _Kernel_cbs
|
|
|
679
679
|
// if we didn't find the method on the prototype, it could be a literal object
|
|
680
680
|
// that implements an interface, so we look if we have the method on the object
|
|
681
681
|
// itself. if we do, we invoke it.
|
|
682
|
-
|
|
682
|
+
//
|
|
683
|
+
//--------------------------------------------------------------
|
|
684
|
+
//
|
|
685
|
+
// huijbers@ (2026) -- I'm pretty sure the above logic is wrong. It reads like
|
|
686
|
+
// looking up methods from the prototype is intended to prevent cyclic calls
|
|
687
|
+
// when subclassing JS classes from a jsii language. We don't want:
|
|
688
|
+
//
|
|
689
|
+
// ```java
|
|
690
|
+
// class MyClass extends JavaScriptClass {
|
|
691
|
+
// public void myMethod() {
|
|
692
|
+
// super.myMethod(); <-- should call myMethod on base class
|
|
693
|
+
// }
|
|
694
|
+
// }
|
|
695
|
+
// ```
|
|
696
|
+
//
|
|
697
|
+
// To call the same `myMethod` again and infinitely recurse, which a naive `invoke(this, 'myMethod')`
|
|
698
|
+
// would do. In order to work around this we seem to be default-ignoring functions
|
|
699
|
+
// that live directly on an object, *unless* we otherwise can't find it on the class.
|
|
700
|
+
//
|
|
701
|
+
// But `#findInvokeTarget()` is used for *all* invokes, and this now finds the wrong
|
|
702
|
+
// method in situations where both a class and the instance have a method, for whatever
|
|
703
|
+
// reason; maybe the JS object got patched or something.
|
|
704
|
+
//
|
|
705
|
+
// At least one case where I ran into this is when calling `toString()` on an anonymous
|
|
706
|
+
// object. Because 'Object.prototype' already has an implementation for `toString`, we
|
|
707
|
+
// never call the one on the anonymous object but always the built-in one which returns
|
|
708
|
+
// "[object Object]".
|
|
709
|
+
//
|
|
710
|
+
// I'm tempted to reverse the logic: look up the method on the instance, *unless* we
|
|
711
|
+
// have reasons to think the object we're looking at is a proxy for a jsii-client object
|
|
712
|
+
// in which case we look up on the parent. But even that is wrong because it would also
|
|
713
|
+
// do the wrong thing in this case:
|
|
714
|
+
//
|
|
715
|
+
// ```java
|
|
716
|
+
// class MyClass extends JavaScriptClass {
|
|
717
|
+
// @Override public void myMethod1() {
|
|
718
|
+
// this.myMethod2(); <-- should call myMethod2 below, not from parent
|
|
719
|
+
// }
|
|
720
|
+
// @Override public void myMethod2() {
|
|
721
|
+
// }
|
|
722
|
+
// }
|
|
723
|
+
// ```
|
|
724
|
+
//
|
|
725
|
+
// Pretty sure this is wrong and needs attention, but for now I'll just make an exception
|
|
726
|
+
// for the one case I need to get working: `toString`.
|
|
727
|
+
let fn;
|
|
728
|
+
// Prototype first, but only if the method is not 'toString'
|
|
729
|
+
if (methodName !== 'toString') {
|
|
730
|
+
fn = instance.constructor.prototype[methodName];
|
|
731
|
+
}
|
|
732
|
+
// Then instance
|
|
733
|
+
fn !== null && fn !== void 0 ? fn : (fn = instance[methodName]);
|
|
683
734
|
if (!fn) {
|
|
684
|
-
|
|
685
|
-
if (!fn) {
|
|
686
|
-
throw new JsiiFault(`Cannot find ${methodName} on object`);
|
|
687
|
-
}
|
|
735
|
+
throw new JsiiFault(`Cannot find ${methodName} on object`);
|
|
688
736
|
}
|
|
689
737
|
return { ti, obj: instance, fn };
|
|
690
738
|
}, _Kernel_validateMethodArguments = function _Kernel_validateMethodArguments(method, args) {
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@jsii/kernel",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.126.0",
|
|
4
4
|
"description": "kernel for jsii execution environment",
|
|
5
5
|
"license": "Apache-2.0",
|
|
6
6
|
"author": {
|
|
@@ -31,19 +31,19 @@
|
|
|
31
31
|
"package": "package-js"
|
|
32
32
|
},
|
|
33
33
|
"dependencies": {
|
|
34
|
-
"@jsii/spec": "1.
|
|
34
|
+
"@jsii/spec": "1.126.0",
|
|
35
35
|
"fs-extra": "^10.1.0",
|
|
36
36
|
"lockfile": "^1.0.4",
|
|
37
37
|
"tar": "^6.2.1"
|
|
38
38
|
},
|
|
39
39
|
"devDependencies": {
|
|
40
|
-
"@scope/jsii-calc-base": "^1.
|
|
41
|
-
"@scope/jsii-calc-lib": "^1.
|
|
40
|
+
"@scope/jsii-calc-base": "^1.126.0",
|
|
41
|
+
"@scope/jsii-calc-lib": "^1.126.0",
|
|
42
42
|
"@types/fs-extra": "^9.0.13",
|
|
43
43
|
"@types/lockfile": "^1.0.4",
|
|
44
44
|
"@types/tar": "^6.1.13",
|
|
45
45
|
"jest-expect-message": "^1.1.3",
|
|
46
|
-
"jsii-build-tools": "^1.
|
|
46
|
+
"jsii-build-tools": "^1.126.0",
|
|
47
47
|
"jsii-calc": "^3.20.120"
|
|
48
48
|
}
|
|
49
49
|
}
|