Currently JS code would have to call the new functions as an extra step after defining the class, which probably isn't as easy as using the 2-argument version of registerClass. So this would just be to let TS code start using the proposed decorator API already and hopefully be forwards compatible with ES decorators in the future.
On Thu, 22 Nov 2018 at 18:22, <philip.chime...@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.) > > 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
_______________________________________________ javascript-list mailing list javascript-list@gnome.org https://mail.gnome.org/mailman/listinfo/javascript-list
