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
_______________________________________________ javascript-list mailing list javascript-list@gnome.org https://mail.gnome.org/mailman/listinfo/javascript-list
