Re: GSJ GIRepository VS Seed
- From: Emmanuele Bassi <ebassi gmail com>
- To: Andrea Giammarchi <andrea giammarchi gmail com>
- Cc: Alan Knowles <alan roojs com>, javascript-list <javascript-list gnome org>
- Subject: Re: GSJ GIRepository VS Seed
- Date: Tue, 22 Mar 2016 11:45:10 +0000
Hi;
On 22 March 2016 at 11:12, Andrea Giammarchi
<andrea giammarchi gmail com> wrote:
Ciao Emmanuele,
I understand what you are saying but I have this kind of
unexpected/undesired scenario:
```js
const
Gio = imports.gi.Gio,
current = Gio.File.new_for_path('/usr/bin/env')
;
print(current.get_path()); // "/usr/bin/env"
print(current instanceof Gio.File); // false <== see this?
```
Are my expectations wrong?
Evidently, yes.
Gio.File (GFile) is an interface; Gio provides multiple
implementations of GFile. Some of these implementation are compiled
in, like local files; others come through IPC, from a separate VFS
daemon.
In GType, GFile would satisfy the relation 'is-a', but it's really a
'does', as GType supports single inheritance for class types, with
additional run time composing through non-instantiable interface
types.
Evidently, the GJS machinery does not/cannot map interfaces using
instanceof — it may very well be impossible to do.
Since it's all GType, on top of turtles, all the way down, you can use:
gjs> let GObject = imports.gi.GObject;
gjs> let Gio = imports.gi.Gio;
gjs> let f = Gio.File.new_for_path('/some/path');
gjs> GObject.type_is_a(f, Gio.File)
true
Am I testing against the wrong "class"?
Is there a known list of private/internal class I can at least manually look at?
No, and you shouldn't do that at all. They are internal for a reason —
i.e. they can conceivably change.
The whole idea of testing for a specific class is, quite frankly, a
blatant layering violation, and it usually indicates some brokenness
in the design of your code.
Ciao,
Emmanuele.
--
https://www.bassi.io
[ ] ebassi [ gmail com]
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]