The DomMatrixReadOnly.m12 issue should be fixed now too. -- Josh Tynjala Bowler Hat LLC https://bowlerhat.dev/
On Wed, Feb 18, 2026 at 10:40 AM Josh Tynjala <[email protected]> wrote: > 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 >> >> >> > >> >>
