Hi;
On 22 March 2016 at 11:12, Andrea Giammarchi
<[email protected]> 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]
_______________________________________________
javascript-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/javascript-list
