Re: camelCase or under_score ?

[Gaspard Bucher <gaspard@...>]

I agree with your particular example: readability is good with underscores in this case (many short words), but the difference is not as strong with things like:

makeGhost

make_ghost

On the one-to-one versus Luaish bindings, I also like bindings that take advantage of the language and offer simpler and more expressive interfaces. For example, my bindings to Qt tend to use closures and functions instead of signals and slots because it's easier on the user's brain to write:

function window.mouse(x, y)

  -- ...

end

then

callback = mimas.Callback(function(x, y)

  -- ...

end)

callback:connect(window, 'mouse')

or even

btn:__addmethod('quitApp()', function(self)

    print("I'm about to close...")

    self:close()

end)

btn:connect('2pressed()', btn, '1quitApp()')

All in all, I think it deeply depends on the goal of the bindings. If they are seen as "an easier way to use X", then one-to-one it should be. If the bindings are "a way to do A by using X, Y and Z", then adapted bindings to ease compatibility between the used libraries and to work nicely with the language seem to be a better choice.

Gaspard

On Thu, Mar 31, 2011 at 10:00 AM, Axel Kittenberger <axkibe@gmail.com> wrote:

>  LexHTMLToXML
>  LexHtmlToXml
>  lex_html_to_xml

However, this example is quite out of context, in that it only shows
the name without the the whole "sentence". The function call should be
one "word" in a complexer statement, and not read as a whole sentence
in itself. Thats the big disadvantage of underscores and the advantage
of camelcase. Non-underscored phrases allow to concentrate on the
grammar of the statement instead of the inner grammar of the function
call.

Otherwise if you make a tight binded library. Go with the syntax of
the library. A negative example is _javascript_/css. The constant
convertions between hypen-seperated-syntax and camelCase are not only
CPU-expensive but also inconsistent. However, in my opinion, too many
"bindings" libraries are just that, one to one relationship. Instead
of providing a more Luaish interface. In that case the Luaish
interface can have different style. Positive example: LuaSocket.