Re: GSJ GIRepository VS Seed

[Andrea Giammarchi <andrea giammarchi gmail com>]

As far as I understand this is probably a GJS limitation but please let's not assume I don't know what I am doing 'cause that sounds just arrogant, thanks.

To quickly explain: in JS inheritance is prototypal and enriching a prototype makes its method available to every derived instance.

There's nothing wrong in this mechanism in the JS world, so nothing is broken or badly designed, that's just how it is in JS (debatable if JS is badly designed but I'm not here to discuss this).

On top of that you wrote "GLocalFile has no public API, and you're supposed to only use the GFile methods"

Now you told me this class is internal for reasons and could change ... so, which one is true: I have to assume it's a GFile but I cannot theoretically trust methods in the GFile interface/prototype ? ... or my expectations are correct, in a JS environment context, where I should be able to trust interfaces and/or/as prototypes and these are extensible and all derived/"is-a" instances should rightly inherits these methods?

I see no solution thought so I'll ended up with a configurable `__noSuchMethod__` in the `GObject.Object.prototype` which is inherited and this just works but since there is a namespace to introspect I was hoping to be able to introspect everything regardless how bad design it is (you should probably also have asked why I am doing that or what's the goal)

Best Regards

On Tue, Mar 22, 2016 at 11:45 AM, Emmanuele Bassi <ebassi gmail com> wrote:

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]