[webkit-dev] webkit glib DOM bindings demo code

[lkcl]

christian wrote:
> 
> Hey Luke,
> 
> I suggest you accept the fact that coding style and naming are a matter
> of preference and convention. A Glib specific binding should really
> adapt the API style, even if there coding style in the implementation
> may differ. If JavaScript sources dominantly use camelCase that's what
> functions in JavaScript should and usually do conform to. If Glib
> interfaces dominantly use under_scores then that's what functions in
> Glib libraries should and usually do conform to.
> 
> It's as simple as that. Convincing anyone of your preferred coding
> and naming style is not going to help. :)
> 
> ciao,
>     Christian
> 

hiya christian, thanks for responding.  back in 1993 when doing
msvc++ programming i found it irritating to be working with
camelCaseFunctions(), thanks to a unix_programming_background().

... that was then :)

the issue i'm raising is not about personal preference, as, actually,
my personal preference is the lowercase underscores!

this is about user expectations, where in _every_ case, every single
language binding to DOM models - without exception - uses camelCase
conventions: anyone who is used to say javascript, or XUL, or
Python-KDE's KHTMLPart language bindings, will look at the lower-casing
and just go "ugh... not again".

so, all the documentation on all 1500 functions and all 300 classes
anywhere that you can read up about javascript and DOM bindings -
anywhere that you can find out _anything_ - it's all using camelCase.
getElementsByTagName(). firstChild. nodeType. appendChild().
createElement(). eventType.  everything.

glib/gobject is therefore clashing - badly - against the expectations,
and it's for _this_ reason that i raise the issue.

also, in the pywebkitgtk python-bindings-to-gobject-bindings-to-gdom
there are functions which i've already had to change the names
of - setProperty i believe was one of them - that clash with the
corresponding glib / gobject function name, once converted to
lower_case_underscored(), clearly.  it may not have been exactly
that one but there are definitely two that clash.

the alternative is that language bindings (such as that provided
by pywebkitgtk) just... convert back to the de-facto convention.

which is messy.

l.
-- 
View this message in context: http://www.nabble.com/webkit-glib-DOM-bindings-demo-code-tp20895913p20897453.html
Sent from the Webkit mailing list archive at Nabble.com.