Re: GSJ GIRepository VS Seed

[Emmanuele Bassi <ebassi gmail com>]

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 type
system.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[ ] ebassi [ gmail com]