Scraper unpredictably transforms some functions into wrong methods
The parsing of .gir
files into documentation seems to exhibit some unpredictable behavior in how it decides to transform some_function_name_with_underscores()
into SomeClass.method_name()
.
For instance, take a look at the "Parsing URIs" section of the GLib.Uri docs, the section immediately after https://gjs-docs.gnome.org/glib20~2.66.1/glib.uri#relative-absolute-uris
Things like g_uri_split()
and g_uri_split_with_user()
in the original docs get transformed into GLib.uri_split
and GLib.uri_split_with_user
, when they should be transformed into GLib.Uri.split
and GLib.Uri.split_with_user
. Yet, g_uri_parse_relative()
correctly becomes GLib.Uri.parse_relative
. Reading the .gir
source, there's no clear reason for the different behavior. One section of GLib-2.0.gir
contains this source:
g_uri_resolve_relative() and g_uri_parse_relative() allow you to
resolve a relative URI relative to a base URI.
g_uri_resolve_relative() takes two strings and returns a string,
and g_uri_parse_relative() takes a #GUri and a string and returns a
#GUri.
Which inexplicably comes out in the docs as:
GLib.uri_resolve_relative and GLib.Uri.parse_relative allow you to resolve a relative URI relative to a base URI. GLib.uri_resolve_relative takes two strings and returns a string, and GLib.Uri.parse_relative takes a GLib.Uri and a string and returns a GLib.Uri.
I haven't been able to find any examples outside of the GLib docs, so far, but there are other issues. Like, at https://gjs-docs.gnome.org/gobject202.66p/gobject.object#method-set_data the documentation claims that 2.66.1/glib.quark_from_string) That page also references GLib.quark_from_string()
returns a GLib.Quark
— but there's no documentation for a GLib.Quark
anywhere. (GLib.quark_from_string()
is documented as a free function, here: https://gjs-docs.gnome.org/glib20GQuark
s, but the reference remains in its markup form as #GQuark
.