Re: Subclassing a GObject in Typescript

[Tony Houghton <h realh co uk>]

On Thu, 22 Nov 2018 at 18:22, <philip chimento gmail com> wrote:

Yes, I would accept a merge request for that.

(Although I'm not sure it's possible to emulate property decorators in current ES.)

I saw in your blog that you want property decorators to work something like this:

@GObject.property.int('Short name', 'Blurb', GObject.ParamFlags.READABLE, 42)
get prop() { /* etc. */ }

I think this should be possible with Typescript decorators. An accessor decorator could add a wrapper to the setter to enforce any constraints on the value and to emit "notify" signals. But could it do the same for a field? Can a decorator replace a simple field with a property definition that includes a setter and/or getter?

I'm struggling in general with all this because I don't even know the formats for the fields in registerClass()'s metaInfo. Is there some thorough documentation for that somewhere?

Interfaces seem to have their own special problem too when it comes to supporting Typescript. ts-for-gjs maps gi interfaces to TS interfaces, but I think in gjs they're implemented as objects which need to be passed to registerClass. Simply using TS' implements keyword probably isn't enough to make whatever registerClass does with interfaces happen, so I think we'd still need an `implements` class decorator. Then we're going to have a problem with TS interfaces clashing with JS objects with the same name. We could work around that by making the decorator factory take the interface name as a string parameter instead of the actual object of that name, but it's a bit ugly. Or perhaps reflect-metadata could make it possible to make the GObject interface setup work just by using TS' implements. Speaking of "implements", being a TS keyword, we probably want a different name for the decorator. Capitalise the first letter?

 

On Tue, Nov 20, 2018 at 8:45 AM Tony Houghton <h realh co uk> wrote:

On second thoughts, we still need to provide definitions for the existing symbols and registerClass(), so ts-for-gjs would be the best place for that. But then I thought why not plan ahead in gjs instead of waiting for a future version of SpiderMonkey/ES to provide decorator support? Can't we just add functions now to overrides/GObject.js that can be used as Typescript decorators already and hopefully be forwards-compatible with ES in the future?

On Mon, 19 Nov 2018 at 17:04, Tony Houghton <h realh co uk> wrote:

That sounds like a good idea, but I think that means we'd currently have to provide extra code at run-time, and ts-for-gjs only provides edit-/compile-time type information for existing introspected code. So it might be better to make this a separate project/package rather than add a new sort of role to ts-for-gjs.

--

TH