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