It would also be useful for people using tools such as Babel with regular ES.
On Fri, Nov 23, 2018 at 10:38 AM Tony Houghton <h...@realh.co.uk> wrote: > 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
