Nice.
> On Feb 19, 2026, at 2:15 AM, Josh Tynjala <[email protected]> wrote:
>
> 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
>>>>>
>>>>
>>>
>>>
