Re: Subclassing a GObject in Typescript

[makepost firemail cc]

You can add multiple signatures per function, following the "Functions" 
and "Do's and Don'ts" pages of the TypeScript documentation. But as 
Philip suggests only binding one form, I'd prefer the argument over the 
decorator, since it's the version already usable in both TypeScript and 
plain JavaScript.

`Partial` marks properties inside as optional, equivalent to adding a 
question mark to each manually. Yes, that signature says that 
registerClass takes a class and returns same class but with optional 
properties.

Implements would have a type `Function[]`, signals would be `{ [key: 
string]: { flags: number, param_types: any[] } }`, probably with some 
change because this is just my first thought.

`${name}_ConstructProps` is a phrase to look for in `main.ts`, context 
will become clear as soon as you find it. Every class derived from 
GObject has its own type for an object containing optional properties 
that can be passed to its constructor.

On 2018-11-19 15:54, Tony Houghton wrote:
> On Fri, 16 Nov 2018 at 18:07, <makepost 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
> > }>`
> > ```
>
> OK. I forgot that there is an optional first argument to registerClass
> which is an object containing the various GObject things such as
> properties and signals to be added to the class. In most languages
> optional arguments have to come last; can Typescript handle them
> coming first?
>
> Things are getting quite hard to understand with that intersection
> type. Does that provide a hint to the compiler that after calling
> registerClass those members will be available on the target class?
> Otherwise I can't work out its purpose. And are you using Partial
> there as an idiom for an anonymous interface? I think all those
> members - [interfaces] etc - don't get added at all if none are
> supplied as the first argument, so should they be marked optional?
>
> > Best not leave it with `any` but specify what types these properties
> >
> > should have.
>
> Yes, but I'm not sure how to deal with them, especially interfaces.
> ts-for-gjs' output defines GObject interfaces as Typescript classes
> with no parent class. If they all derived from, say a class called
> GInterface, I think I could call their type 'typeof GInterface'. But
> 'function' or 'object' don't seem to be valid Typescript type names,
> so I'm stuck.
>
> > _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.
>
> Sorry, I got lost at `${name}_ConstructProps`.
>
> > 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
>
> --
>
> TH