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 <eba...@gmail.com> wrote:
> Hi;
>
> On 22 March 2016 at 11:12, Andrea Giammarchi
> <andrea.giammar...@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]
>
_______________________________________________
javascript-list mailing list
javascript-list@gnome.org
https://mail.gnome.org/mailman/listinfo/javascript-list
