[Webkit-unassigned] [Bug 16401] [GTK] GObject/C DOM binding

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Feb 11 10:00:51 PST 2009


https://bugs.webkit.org/show_bug.cgi?id=16401





------- Comment #153 from xan.lopez at gmail.com  2009-02-11 10:00 PDT -------
(In reply to comment #151)
> > > When are properties actually useful?
> > 
> > Another very important point is that they allow automatic binding generation
> > through gobject-introspection with the right semantics.
> 
> gobject-introspection is aware of both properties and methods.  The Vala
> bindings generator, for example, uses (a version of) gobject-introspection to
> find out about GObject classes. Each GObject property becomes a Vala property,
> and each GObject method becomes a Vala method.  With the current patch DOM
> objects have both properties and getters/setters, and all of these end up
> reflected into the Vala world.  So in Vala you could write either
> node.parent_node or node.get_parent_node(), for example.

Sure. Many bindings do this, the old ones not using gobject-introspection too.
For instance foo.get_bar() vs foo.props.bar in PyGObject, IIRC.

> 
> It's not clear to me what you mean by "the right semantics" here.  Are you
> asserting that DOM attributes should be reflected into higher-level languages
> as properties in those languages, and that gobject-introspection can enable
> that only if they are available as GObject properties?

Yes, I meant exactly that. You can construct high-level properties from the
getters/setters, but then you'd have to do this manually (like in the example
Luke has written). Of course I'm assuming you actually want to use DOM
properties as properties in your language, which is the next point.

> Is there some specific application or use case that will suffer if attributes > are available only through getters/setters?

Well, one big point IMHO is the discoverability of the API. At least in my case
I'd expect to have DOM properties accessible as actual properties of an object,
and not only as getters/setters. I expect I won't be alone in this, so forcing
bindings authors to do this manually seems like a big point for me.

Another property of properties (pun not intended ;)) that I've used heavily in
languages like JavaScript or Lisp is the hability to programatically generate
the names of the properties you want to read or set. Depending on the language
this can be done more or less easily with functions too, but in general it's
considerably more cumbersome.

And of course there's notifies, but Brian has told us that enabling that would
probably be a big performance issue, so I guess we can leave that out (at least
for now).


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list