How does gjs handle name clashes between fields and methods of records?

[realh (Tony Houghton)]

I’m working on/with ts-for-gjs and found some problems when trying to map GstIterator and GstTypefind. These are “records” in the gir file and they have some name clashes between methods and fields which are function pointers. For example:

export class Iterator {
    // Fields of Gst.Iterator
    copy: IteratorCopyFunction
    next: IteratorNextFunction
    resync: IteratorResyncFunction
    free: IteratorFreeFunction
    // Instance and signal methods
    copy(): Iterator
    free(): void
    next(): [ /* returnType */ IteratorResult, /* elem */ any ]
    resync(): void
}

What does gjs do in this situation? The fields are function pointers/callbacks with the same signatures as their respective methods, so whether gjs exposes the field or the method ultimately shouldn’t make much difference in this case. But I just wanted to check first, in case gjs does something I hadn’t predicted, or in case there are other clashes in libraries I haven’t tested yet, where the signatures don’t match; then it would be important to know what gjs does.

[sdroege (Sebastian Dröge)]

I don’t know how gjs handles this specific case, but usually you don’t want to give direct access to struct fields automatically but require some kind of opt-in per type. There are usually all kinds of invariants on the fields that can’t be automatically ensured, and in a type-safe language like TS you probably want to make things as safe as possible

In this specific case, I don’t think you will be able to auto-generate nice bindings for GstIterator and GstTypefind. Using existing instances and passing them to the functions should be fine, but defining new instances will require some manual bindings code.