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.
On Sat, 17 Nov 2018 at 02:46, <philip.chime...@gmail.com> wrote:
> If you decide to export a TypeScript API, I think it would be better to
> set it up as it was intended for regular JavaScript. The current API in GJS
> is considered transitional, until we get class and property decorators and
> data properties in JavaScript proper.
>
> The API usage will likely look like something like this, when that happens:
>
> @GObject.registerClass
> class Spinner extends Gtk.Widget {
> static [GObject.interfaces] = [Gtk.Orientable, Gtk.Buildable]
> static [GObject.signals] = {
> 'foobars-incremented': {},
> }
>
> _init(props = {}) {
> ...
> }
>
> @GObject.property({
> description: 'The number of foobars',
> type: GObject.TYPE_INT,
> })
> get foobars() {
> return 42;
> }
> }
>
> All of this should actually work already with the equivalent JS function
> calls and "static get" properties, although I'm not sure anyone ever tests
> it. (The one thing that won't work is the GObject.property() decorator
> which isn't possible to emulate in current JS.)
> But if I'm not mistaken all these things already have equivalents in
> TypeScript, so it would be nice to have the TypeScript API look like the
> intended API in JS.
>
> Regards,
> Philip
>
> On Fri, Nov 16, 2018 at 1:07 PM <makep...@firemail.cc> wrote:
>
>> A generic seems appropriate, here's how you can start:
>>
>> ```ts
>> export function registerClass<T>(klass: T): T & Partial<{
>> [interfaces]: any[]
>> [properties]: any
>> [requires]: any[]
>> [signals]: any
>> }>`
>> ```
>>
>> Best not leave it with `any` but specify what types these properties
>> should have.
>>
>> _init should receive `${name}_ConstructProps` for proper checking, not
>> just any object. Look for the push of "default constructor", and add the
>> _init definition nearby, that should be enough.
>>
>> On 2018-11-16 15:56, Tony Houghton wrote:
>> > I want to make ts-for-gjs work with registerClass(), but as a
>> > Typescript beginner I would appreciate some advice. I'm proposing to
>> > make it add these globals to GObject.d.ts:
>> >
>> > export function registerClass(klass: Object): Object
>> > export declare const interfaces: unique symbol
>> > export declare const properties: unique symbol
>> > export declare const requires: unique symbol
>> > export declare const signals: unique symbol
>> >
>> > Does that look OK? I'm not 100% sure that Object is the most
>> > appropriate type to use for registerClass' parameter and return value.
>> >
>> > GObject.Object needs this pseudo-constructor:
>> >
>> > _init(params?:object): void
>> >
>> > but is the base class the only one that needs that, or is it
>> > overridden in all subclasses?
>> >
>> > When registerClass() is called, it adds the equivalent of these static
>> > members to the class being registered:
>> >
>> > static [interfaces]?: any[]
>> > static [properties]?: object
>> > static [requires]?: any[]
>> > static [signals]?: object
>> >
>> > Seeing as they're added dynamically to 3rd party classes, but aren't
>> > present in the introspected classes, I don't think we can actually get
>> > ts-for-gjs to do anything about them. Any ideas on how these could be
>> > made convenient to use in Typescript?
>> >
>> > --
>> >
>> > TH
>> > _______________________________________________
>> > javascript-list mailing list
>> > javascript-list@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/javascript-list
>> _______________________________________________
>> javascript-list mailing list
>> javascript-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/javascript-list
>>
>
--
TH
_______________________________________________
javascript-list mailing list
javascript-list@gnome.org
https://mail.gnome.org/mailman/listinfo/javascript-list
