If you're parsing the GIR, there's an "abstract" attribute for abstract classes.
If you're using the GIRepository API, you can use
`g_object_info_get_abstract()` to know if a type is abstract.
Ciao,
Emmanuele.
--
On 8 November 2017 at 16:40, Sam Jansen <sam jansen starleaf com> wrote:
> Perhaps you can check whether any methods are constructors? This is
> effectively the information I look at when parsing GIR files for my TS
> definitions...
>
> http://devdocs.baznga.org/girepository20~2.0_api/ girepository. functioninfoflags#default-is_ constructor
>
> On 8 November 2017 at 12:37, Andrea Giammarchi <andrea giammarchi gmail com>
> wrote:
>>
>> the documentation doesn't say if I can instantiate those classes, or does
>> it?
>>
>> if I could understand via GIRepository.Repository if a class could be
>> extended/instantiated I could improve cgjs-about to show that right away.
>>
>> So far I thought that `objects` where all usable as `new Class` but that's
>> not the case at all. Maybe I should check for an `is_abstract_object` ?
>>
>> Not sure there is anything like that though.
>>
>> Thanks.
>>
>>
>> On Wed, Nov 8, 2017 at 3:41 AM, <philip chimento gmail com> wrote:
>>>
>>> This comes a bit too late to help you, sorry, but the C docs will tell
>>> you which classes extend a base class, e.g. for GInputStream
>>> (Gio.InputStream in GJS):
>>> https://developer.gnome.org/gio/stable/GInputStream.html# GInputStream.object-hierarchy
>>>
>>> On Tue, Nov 7, 2017 at 2:36 PM Andrea Giammarchi
>>> <andrea giammarchi gmail com> wrote:
>>>>
>>>> so, just FYI ...
>>>>
>>>> Buffered, Converter, Data, File, Memory and Unix InputStream are
>>>> available.
>>>>
>>>> Buffered, Converter, and Data need a base_stream to work ... not a
>>>> primitive.
>>>>
>>>> File and Unix need attributes or fd pointers
>>>>
>>>> The Memory seems to be the "base/primitive" I was looking for together
>>>> with its MemoryOutputStream counterpart.
>>>>
>>>> Regards
>>>>
>>>>
>>>>
>>>> On Tue, Nov 7, 2017 at 7:28 PM, Andrea Giammarchi
>>>> <andrea giammarchi gmail com> wrote:
>>>>>
>>>>> oh gosh, my own utility ... that is less useful in pretty print for
>>>>> these kind of things .... although the list has many non-usable streams but
>>>>> now I want to know which one is usable.
>>>>>
>>>>> P.S. for namespaces you don't' need gi prefix ... cgjs-about Gio would
>>>>> do the same ;-)
>>>>>
>>>>> Thanks again
>>>>>
>>>>> On Tue, Nov 7, 2017 at 7:09 PM, Sam Jansen <sam jansen starleaf com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7 November 2017 at 21:55, Andrea Giammarchi
>>>>>> <andrea giammarchi gmail com> wrote:
>>>>>>>
>>>>>>> this is gold, thank you!!!
>>>>>>>
>>>>>>> do you know if MemoryInputStream is the only one usable? is there any
>>>>>>> list of available GJS streams one can use? I think memory is just fine
>>>>>>> though, thanks again a lot!
>>>>>>>
>>>>>>
>>>>>> I just took an educated guess: I figured anything useful would extend
>>>>>> Gio.InputStream. I then just browsed through the docs, looking for anything
>>>>>> with "InputStream" in their name, which isn't so many...
>>>>>>
>>>>>> This is a good place to start perhaps:
>>>>>>
>>>>>> $ cgjs-about gi.Gio --json | grep InputStream | grep -Ev
>>>>>> "Class|Private"
>>>>>>
>>>>>>
>>>>>> It would be a neat extension to cgjs-about if one could have it list
>>>>>> the classes known to implement an interface or extend from a class...
>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 7, 2017 at 6:46 PM, Sam Jansen <sam jansen starleaf com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Andrea,
>>>>>>>>
>>>>>>>> I've come up with something that... almost does what you're looking
>>>>>>>> at here. Perhaps it's useful as a guide of what one can do with the Gio
>>>>>>>> interface.
>>>>>>>>
>>>>>>>> I think you may hit some awkward problems with modelling Node-style
>>>>>>>> streams with GLib ones. But perhaps it is possible and this helps. I don't
>>>>>>>> really know the Node stream semantics so I have assumed various things in my
>>>>>>>> Readable implementation as you'll see... Note that MemoryInputStream really
>>>>>>>> is just a byte stream; so there is no guarantee you'll receive the exact
>>>>>>>> block of bytes that was written -- for example, when I run this I get a
>>>>>>>> first chunk of "12", followed by "3", "4", etc.
>>>>>>>>
>>>>>>>>
>>>>>>>> let Gio = imports.gi.Gio;
>>>>>>>> let byteArray = imports.byteArray;
>>>>>>>> let mainloop = imports.mainloop;
>>>>>>>>
>>>>>>>> class Readable {
>>>>>>>> constructor() {
>>>>>>>> this._mio = Gio.MemoryInputStream.new();
>>>>>>>> this._callbacks = {};
>>>>>>>> this._startNext();
>>>>>>>> }
>>>>>>>>
>>>>>>>> _startNext() {
>>>>>>>> // Enqueue an async read; and re-enqueue when it finishes, so
>>>>>>>> we're
>>>>>>>> // always waiting for data...
>>>>>>>> this._mio.read_bytes_async(4096, 1, null, (source, res) => {
>>>>>>>> this._onData(this._mio.read_bytes_finish(res));
>>>>>>>> this._startNext();
>>>>>>>> });
>>>>>>>> }
>>>>>>>>
>>>>>>>> _onData(bytes) {
>>>>>>>> if (this._callbacks['data']) {
>>>>>>>> let ba = byteArray.fromGBytes(bytes);
>>>>>>>> this._callbacks['data'](ba);
>>>>>>>> this._read();
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> push(bytes) {
>>>>>>>> if (bytes == null) {
>>>>>>>> mainloop.quit('main');
>>>>>>>> return;
>>>>>>>> }
>>>>>>>> this._mio.add_bytes(bytes);
>>>>>>>> }
>>>>>>>>
>>>>>>>> on(name, callback) {
>>>>>>>> this._callbacks[name] = callback;
>>>>>>>> if (name === 'data') {
>>>>>>>> this._read();
>>>>>>>> }
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> class Counter extends Readable {
>>>>>>>> constructor(opt) {
>>>>>>>> super(opt);
>>>>>>>> this._max = 1000;
>>>>>>>> this._index = 1;
>>>>>>>> }
>>>>>>>>
>>>>>>>> _read() {
>>>>>>>> const i = this._index++;
>>>>>>>> if (i > this._max)
>>>>>>>> this.push(null);
>>>>>>>> else {
>>>>>>>> const str = '' + i;
>>>>>>>> const buf = byteArray.fromString(str); // Buffer.from(str,
>>>>>>>> 'ascii');
>>>>>>>> this.push(buf);
>>>>>>>> }
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> (new Counter).on('data', (str) => {
>>>>>>>> print("data", str.toString());
>>>>>>>> });
>>>>>>>>
>>>>>>>> mainloop.run('main');
>>>>>>>>
>>>>>>>>
>>>>>>>> On 7 November 2017 at 10:08, Andrea Giammarchi
>>>>>>>> <andrea giammarchi gmail com> wrote:
>>>>>>>>>
>>>>>>>>> I am trying to implement a stream module and apparently I have
>>>>>>>>> everything I need but practically I'm unable to use streams.
>>>>>>>>>
>>>>>>>>> If I instantiate a `new Gio.InputStream` I have the following
>>>>>>>>> error:
>>>>>>>>> cannot create instance of abstract (non-instantiatable) type
>>>>>>>>> 'GInputStream'
>>>>>>>>>
>>>>>>>>> I cannot even extend it ... so I've though "ok, maybe it's like an
>>>>>>>>> interface, I implement it and that's it"
>>>>>>>>>
>>>>>>>>> But then a JS class wouldn't work as base_stream for a
>>>>>>>>> Gio.BufferedInputStream, and if I extend the JS class to be a GObject.Object
>>>>>>>>> then:
>>>>>>>>> Gjs-WARNING **: JS ERROR: TypeError: Object is of type
>>>>>>>>> GObject.Object - cannot convert to GInputStream
>>>>>>>>>
>>>>>>>>> where GInputStream is the one I cannot use in the first place.
>>>>>>>>>
>>>>>>>>> I've reached full circle then so ... I wonder if anyone has any
>>>>>>>>> idea how to use/create/extend streams in GJS (not talking about file streams
>>>>>>>>> but streams in general) or if it's even possible.
>>>>>>>>>
>>>>>>>>> In node, as example, I could do this and it will work:
>>>>>>>>>
>>>>>>>>> ```js
>>>>>>>>>
>>>>>>>>> const { Readable } = require('stream');
>>>>>>>>>
>>>>>>>>> class Counter extends Readable {
>>>>>>>>> constructor(opt) {
>>>>>>>>> super(opt);
>>>>>>>>> this._max = 1000;
>>>>>>>>> this._index = 1;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _read() {
>>>>>>>>> const i = this._index++;
>>>>>>>>> if (i > this._max)
>>>>>>>>> this.push(null);
>>>>>>>>> else {
>>>>>>>>> const str = '' + i;
>>>>>>>>> const buf = Buffer.from(str, 'ascii');
>>>>>>>>> this.push(buf);
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> (new Counter).on('data', console.log);
>>>>>>>>>
>>>>>>>>> ```
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> _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
>>
>>
>
>
> _______________________________________________
> _javascript_-list mailing list
> _javascript_-list gnome org
> https://mail.gnome.org/mailman/listinfo/_javascript_- list
>
https://www.bassi.io
[@] ebassi [@gmail.com]