Ok, let's try a factual response...
Oops; that will teach me to check first and not try to answer from memory :-/
On Tue, 2016-03-22 at 17:24 +0000, Andrea Giammarchi wrote:
> > There is not even any Gio.LocalFile known to JS.
>
> ```js
> const a = imports.gi.Gio.File.new_for_path('./a.js');
>
> // here the "now known to JS" Gio.LocalFile.prototype
> Object.getPrototypeOf(a).shenanigans = true;
>
> const b = imports.gi.Gio.File.new_for_path('./b.js');
>
> // all instances affected indeed
> print(b.shenanigans); // true
> ```
>
> > It's not exposed in the GIR file, so there is never a prototype
> object created in the first place
Yes, there is a prototype object created. Every JS object with custom
behavior has a custom prototype object in SpiderMonkey, that's just how
it is.
This prototype object is "GLocalFile", and it's stored in an invisible
object that exists just to reference it, as well as other hidden
classes that appear through GType but not through introspection.
It's supposed to be mostly invisible, but it's unavoidable.
> There is:
>
> ```js
> const a = imports.gi.Gio.File.new_for_path('./a.js');
> // here the *shared* Gio.LocalFile.prototype
> Object.getPrototypeOf(a);
> ```
>
> > In GJS, you can check if an object implements an interface with
> myObj.constructor.implements(Gio.File).
>
> That's good to know, thanks, yet if you read first messages of this
> thread it was about patching upfront and not at runtime.
> I understand I can find at runtime pretty much anything I want, but
> since there is an introspection ability, why are there undocumented
> instances around with undocumented prototypes?
>
> Or better, why `Gio.File.new` creates something unrelated with
> `Gio.File.prototype` or `Gio.File` methods ?
> Since this super secret thing is easily leaked, why not fixing this
> instead of saying that it shouldn't be known?
You can't fix that.
The truth is, Gio.File is a lie.
Indeed, Gio.File.prototype.replace_contents !==
(Gio.File.new_for_path('/foo')).replace_contents
What it means is that Gio.File is an object that exists only to hold
methods that quack like the actual interface methods, if you call them
explicitly with say
Gio.File.prototype.replace_contents.call(file, "bla")
, but has nothing to do with the interface methods exposed on each
object.
The reason for this is that prototype inheritance is single, but a
GObject class can have multiple interfaces, so there is no good place
to put Gio.File.prototype on the prototype chain from file to
Object.prototype (in a way that's generic and consistent with say,
Gtk.Label and Gtk.Buildable).
So what happens is that every class that also implements an interface
will resolve all interface methods on its own prototype.
In the Gtk.Label case, Gtk.Label implements Gtk.Buildable and
Gtk.Widget implements Gtk.Buildable, both visible in the GIR, which
means
Gtk.Label.prototype.hasOwnProperty('custom_tag_start') === true
and
Gtk.Widget.prototype.hasOwnProperty('custom_tag_start') === true
In the GLocalFile case, GLocalFile implements Gio.File, and we know
that from GType at runtime, so
window.<invisible name>.GLocalFile.prototype.hasOwnProperty('replace_contents') === true
but you don't know that unless you poke at Object.getPrototypeOf
Yes, this is very awkward if you monkey patch prototypes, but that's
just how it is.
> The reason I've asked is that I've discovered there are hidden
> classes the GIR won't tell me, doesn't know, but **are** on my way.
>
> > I don't believe Spidermonkey would support overloading instanceof
> for this
>
> `instanceof` is the most easily "overloaded" ( not actually
> overloaded, it just checks
> `rightSide.prototype.isPrototypeOf(leftSide)` ) operator which is why
> I am asking if this would ever be solved.
Now, if we tell a lie, we should at least be consistent about it, and
that's why
Gio.File.new_for_path('/') instanceof Gio.File
should return true
Checking the prototype would not work, but instanceof can be overloaded
"properly", because after all we have access to the C API of SM and we
can do what we want.
Indeed, that's https://bugzilla.gnome.org/show_bug.cgi?id=587030
which has had patches for a while and probably needs a rebase, but
would make the Gio.File lie less visible to programmers.
Hope this clarifies the situation, and cheers,
Giovanni
