> You should not assume that, just because you're using a _javascript_> syntax, the underlying mechanisms are written with _javascript_ in mind.fair enough, but to be more precise:I'm assuming a type system exposed to JS would look and behave as JS as possible.Regardless, if I know that `obj is-a Type` I expect `obj` to expose things available in `Type`Why would a private runtime created object that would like to act `as-Type` not inherit or overload itself with `Type` features?If I can read `Gio.File` interface and its methods, properties, etc, I'd expect any internal "class" should be able too.I understand the cost of runtime analysis per each instance is an absolute no-go but would it be possible to lazily expose to JS the internal `GLocalFile` as prototype of GFile?
After all, all it takes to swap a prototype in JS is `Object.setPrototypeOf(GLocalFile.prototype, GFile.prototype)` where in GJS the polyfill for such ES6/2015 method is```jsObject.setPrototypeOf = (set => (target, proto) => (set.call(target, proto), target))(Object.getOwnPropertyDescriptor(Object.prototype, '__proto__').set);```Having a *similar* prototype switch before exposing it to the outer Env would match normal/daily JS expectations where yet there are no interfaces or structs, just some sugar for classes and nothing else.Best RegardsOn Tue, Mar 22, 2016 at 12:11 PM, Emmanuele Bassi <ebassi gmail com> wrote:Hi;
On 22 March 2016 at 11:59, Andrea Giammarchi
<andrea giammarchi gmail com> wrote:
> 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.
That was not my intention.
> To quickly explain: in JS inheritance is prototypal and enriching a
> prototype makes its method available to every derived instance.
You're also assuming that I don't know anything about _javascript_,
here, so I'd ask you to extend me the courtesy of not being
condescending.
> On top of that you wrote "GLocalFile has no public API, and you're supposed
> to only use the GFile methods"
Yes. GLocalFile is a private implementation of GFile.
When you create a GFile instance through one of its factory methods,
you're given an opaque object for which you only have two guarantees:
* it's GObject instance
* it implements the contract of the GFile interface
> 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?
You're assuming that what gets created maps to the _javascript_ object
model — which it does, up to a point, until you get to see the seams
between the GObject type system and the _javascript_ one.
GObject is a class-based, single inheritance type system that allows
some form of multiple inheritance via semi-abstract interface types
(they are semi-abstract because they can have some internal state
which makes them something closer to mixins). You should not be
looking at it as a prototype based type system, like _javascript_.
Wherever possible, the latter type system is mapped onto the former,
but there are obvious places where that's not possible, or it's very
complicated to do so efficiently or within the scope of the ECMA
standard.
You should not assume that, just because you're using a _javascript_
syntax, the underlying mechanisms are written with _javascript_ in mind.
> 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)
I would have asked, but it seems to me that your puzzlement is
stemming here from a misunderstanding of how the moving pieces fit
together — probably because you're not accustomed to the GObject typessystem