Yes, I would accept a merge request for that. (Although I'm not sure it's possible to emulate property decorators in current ES.)
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. >> >
_______________________________________________ javascript-list mailing list javascript-list@gnome.org https://mail.gnome.org/mailman/listinfo/javascript-list
