Because that's a simple case. The length argument is not always at the end.
On Fri, Mar 1, 2013 at 7:03 AM, Matteo Settenvini <matteo...@member.fsf.org>wrote: > Il giorno gio, 28/02/2013 alle 01.51 -0800, Simon Feltman ha scritto: > > On Thu, Feb 28, 2013 at 12:04 AM, Martin Pitt <martin.p...@ubuntu.com> > > wrote: > > Nikita Churaev [2013-02-27 23:26 +0400]: > > > 3. Gtk.TextBuffer.set_text(text, length) --- length argument > > is useless, > > > since JavaScript uses UTF-16 and length expects length of > > UTF-8 string. > > > > > > I'm afraid we have to live with little oddities like this. I > > think > > it's better to stay compatible with the C API and its > > documentation, > > and all currently existing JavaScript program which use the > > API than > > breaking API and continuously chasing after weird cases like > > that. > > > > > > I don't think skipping the length arg in this case could work even if > > API breakage was acceptable. I assume a skip implies a value of zero > > is used and in this case that would not work. A better alternative > > would be default value support. This way the oddity can be avoided in > > client code without breaking API and in general would be a very nice > > feature. However, new code using this would need to specify it only > > works with advanced versions of GLib or the libraries providing > > defaults. > > > > > > https://bugzilla.gnome.org/show_bug.cgi?id=558620 > > > > > > -Simon > > > > Uhm, I thought JavaScript ignored extra arguments to a function: > > $ gjs > gjs> function f (a) { }; > gjs> f (1, 2, 3); > (no error) > > Then, why not changing the JS API to provide only > "Gtk.TextBuffer.set_text (text);"? > > It would break no existing code. > > In turn, *.set_text(text) calls the non-exported, "private", > two-argument version, by computing the right UTF-8 length. > > Something like: > > let (f = Gtk.TextBuffer.set_text) > { > Gtk.TextBuffer.set_text = function (text) > { > var l = ... // get the right "text" length for UTF-8 > return f (text, l); > } > } > > That way, you also solve a lot of programming errors in locales other > than C, providing an easier interface. > > You just need a couple of overrides to do so. Similar functions would be > trivial to manage. > > Cheers, > -- > Matteo Settenvini > FSF Associated Member > Email : mat...@member.fsf.org > > > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GCS/E d--(-) s+: a- C+++ UL+++ > P+ L++++>$ E++>+++ W+++ N+ o? > w--- O M- V- PS++ PE- Y+>++ > PGP+++ t++ 5 X- R+ !tv b+++ > DI++ D++ G++ e++ h+ r++ y+ > ------END GEEK CODE BLOCK------ > > > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Jasper
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
