Re: GJS camelCase methods (at least)

[philip chimento gmail com]

Hi Andrea,

On Wed, Oct 11, 2017, 23:28 Andrea Giammarchi <andrea giammarchi gmail com> wrote:

I've updated to GJS 1.50 (and I've seen 1.54 is actually the latest) and things are becoming better and better on daily basis.

I appreciate it! 1.50 is the latest stable though, there's certainly no 1.54.

Seeing that I can also extends Gtk classes without needing the (obsolete?) Lang namespace is wonderful, yet beside having almost fully implemented ES2015 syntax I've seen zero changes in terms of "camelCasization".

I've created a method that does only that [1] so that I can write code like the following one and see it working without a glitch.

```js

const Gtk   = imports.gi.Gtk;

Gtk.init(null);

class Dialog extends camelPatched(Gtk.Window) {

  constructor(...args) {

    super(...args);

    this.connect('show', () => {

      this.setKeepAbove(true);

      Gtk.main();

    });

    this.connect('destroy', () => Gtk.main_quit());

  }

}

const win = new Dialog({

  type: Gtk.WindowType.TOPLEVEL,

  window_position: Gtk.WindowPosition.CENTER

});

win.setDefaultSize(200, 80);

win.add(new Gtk.Label({label: 'Hello GJS!'}));

win.showAll();

```

Now, I understand that properties and configuration objects might require huge time/resources investment but can we please consider a migration plan for at least camelCase methods?

Or could we at least add a method that does basically exactly the same thing I am doing so that GJS could offer a more JS friendly environment?

Thanks in advance for any sort of outcome.

[1] https://gist.github.com/WebReflection/c1a438d90708e71cf1f2bd742a721311

We did discuss this already on the mailing list. My thoughts have not changed in the meantime: I agree it's inconsistent but essentially a cosmetic problem. I would welcome, and gladly code-review, a contributed fix, on the condition that it doesn't slow down existing property accesses or mess up stack traces, but I'm not planning to fix it right now myself.

Note that camel case property names and configuration objects really do already work as far as I know!

If you would like to pick this task up, I think it can be done in object_instance_resolve() in gi/object.cpp without slowing down existing accesses. The tedious part might be adding regression tests and handling weird cases such as get_html -> getHtml vs. getHTML.

Regards,

Philip