On Tue, Mar 22, 2016, 05:25 Andrea Giammarchi <andrea.giammar...@gmail.com> wrote:
> > 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? > There is not even any Gio.LocalFile known to JS. It's not exposed in the GIR file, so there is never a prototype object created in the first place. > > 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 > > ```js > Object.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 Regards > > > > > On Tue, Mar 22, 2016 at 12:11 PM, Emmanuele Bassi <eba...@gmail.com> > wrote: > >> Hi; >> >> On 22 March 2016 at 11:59, Andrea Giammarchi >> <andrea.giammar...@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? >> > In GJS, you can check if an object implements an interface with myObj.constructor.implements(Gio.File). I don't believe Spidermonkey would support overloading instanceof for this. > >> 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 type > > ssystem > > Best, Philip >
_______________________________________________ javascript-list mailing list javascript-list@gnome.org https://mail.gnome.org/mailman/listinfo/javascript-list
