Re: Supporting attribute-like properties

[C Anthony Risinger <anthony xtfx me>]

On Sat, May 26, 2012 at 1:50 AM, Simon Feltman <s feltman gmail com> wrote:
> Hi Kerrick,
>
> Properties on classes and objects pulled in through introspection have a
> "props" accessor. So with your example but using myLabel.props.angle should
> already work.
>
> If the GObject property was created in python, then the property will be
> directly accessible on the object as well (GObject.Property supports the
> descriptor and decoration protocols similar pythons built-in "property")
>
> from gi.repository import GObject
> class Label(GObject.GObject):
>     angle = GObject.Property(type=float)
> myLabel = Label()
> myLabel.angle = myLabel.angle + 180

interesting ... i am working on a bindings to pygi+webkit for an
existing project that already runs on several other engines
(Trident/XULRunner/PythonWebKit), and one of the problems is our DOM
code (among others) expects attributes to be available per the W3C
specs, eg. window.getLocation(), document.createElement() and the like
... ie. camelCase.

my current approach is to hijack __getattr__ and __setattr__ for key
classes related to DOM/etc, and, in the simple case, inject camelCase
"aliases" to gobject_attributes as needed, this seems to work pretty
good as camelCase is all-but-guaranteed to fail *one time*; once set
there is no performance penalty.

however, attributes on `.props` require a different approach ... so i
am instead dynamically generating a descriptor that does little more
than call `instance.get_property(some_property)`.  so far i've seen no
ill-effects but it's not well tested ... is there a penalty-free way
to do this as well?

the code is *very* experimental and nasty looking, but it's all done
in this one function:

https://github.com/pyjs/pyjs/blob/develop-giwebkit/pyjd/giwebkit.py#L62

... not trying to derail the thread here, but i have the same "issue"
so-to-speak; is there a better/cleaner way to do all of this?  i need
to expose gobject_based_attrs and methods in a more "javascript-y",
W3C kind of way ... what would you suggest?  and is there any
considerations i should be aware of in my current approach?

-- 

C Anthony