I've fixed the bodyUsed Object/Boolean issue. It was exactly as I suspected. We had logic to check for @override on methods and get the type from the interface, but not for @override on fields.
It looks like the DomMatrixReadOnly.m12 one is because we're skipping some implemented interfaces in the hierarchy. We check all of the interfaces from the class and its super classes. However, we're skipping any additional interfaces that the first set of interfaces are extending. I should get that working later today too. -- Josh Tynjala Bowler Hat LLC https://bowlerhat.dev/ On Wed, Feb 18, 2026 at 9:13 AM Harbs <[email protected]> wrote: > I think I see the pattern: > > DOMMatrixReadOnly implements DOMMatrixInit > > DOMMatrixInit extends DOMMatrix2DInit > > Any getters and setter defined in DOMMatrixInit are compiled as > getters/setters > > Any getters and setters in the super interface (DOMMatrix2DInit) becomes > vars. > > Definitely seems like a bug... > > > On Feb 18, 2026, at 7:09 PM, Harbs <[email protected]> wrote: > > > > Another really weird one: > > > > /** > > * @type {number} > > * @see https://www.w3.org/TR/geometry-1/#dom-dommatrixreadonly-m12 > > */ > > DOMMatrixReadOnly.prototype.m12; > > > > /** > > * @type {number} > > * @see https://www.w3.org/TR/geometry-1/#dom-dommatrixreadonly-m13 > > */ > > DOMMatrixReadOnly.prototype.m13; > > > > Becomes: > > > > /** > > * @see JSType - [number] > > * @see https://www.w3.org/TR/geometry-1/#dom-dommatrixreadonly-m12 > > * @see [w3c_geometry1] > > */ > > public var m12:Number; > > > > /** > > * @see JSType - [number] > > * @see https://www.w3.org/TR/geometry-1/#dom-dommatrixreadonly-m13 > > * @see [w3c_geometry1] > > */ > > public function get m13():Number{ return 0; }; > > public function set m13(value:Number):void{}; > > > > > > Why did m12 get compiled as a var, while m13 became getters/setters? > > > > (The var causes an error.) > > > > That was just one sampling. Some properties get compiled as varsity and > others as setters/getters. > > > > I did not see any pattern. > > > >> On Feb 18, 2026, at 4:47 PM, Harbs <[email protected]> wrote: > >> > >> That issue came from fecthapi.js > >> > >> Other files have other issues. > >> > >>> On Feb 18, 2026, at 12:32 PM, Yishay Weiss <[email protected]> > wrote: > >>> > >>> Which externs file are you using? > >>> ________________________________ > >>> From: Harbs <[email protected]> > >>> Sent: Wednesday, February 18, 2026 12:12 PM > >>> To: Apache Royale Development <[email protected]> > >>> Subject: typedefs > >>> > >>> I’m trying to add more js typedefs and I’m running into issues. > >>> > >>> One issue I just ran into is: > >>> > >>> /** @type {boolean} */ > >>> Body.prototype.bodyUsed; > >>> > >>> > >>> /** @override */ > >>> Request.prototype.bodyUsed; > >>> > >>> /** @override */ > >>> Response.prototype.bodyUsed; > >>> > >>> > >>> Request and Response both: > >>> * @implements {Body} > >>> > >>> When compiling, we get an error because the Request and Response > setters/getters are typed to “Object”, while the Body ones are correctly > types as Booleans. > >>> > >>> It seems like externc does not find the inherited types using > @implements. > >>> > >>> Is this a bug? Something not implemented? Is it easy to fix? > >>> > >>> We can add more files to the list we maintain in royale-extras, but > I’d like to reduce that rather than increase it. > >>> > >>> Thoughts? > >>> > >>> Harbs > >> > > > >
