> 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 ```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? > > 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 > system. > > 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
