[Development] Feature freeze exception for QTBUG-95587

[Edward Welbourne]

On 2021 Sep 13, at 20:58, Elvis Stansvik <elvstone at gmail.com<mailto:elvstone at gmail.com>> wrote:
>> Yes, URLs are vital to QML I guess, but are they *that* vital? The
>> bar should be quite high IMO. In the apps I've worked on, URLs and
>> URL handling is really not central at all.

IIUC, the present work has to do with the fact that things you might not
be thinking of as URLs really are - at least under the QML bonnet - such
as references to assets you ship with your QML application; the images,
textures and so on, that you might think of as "file-names" are
apparently handled as URLs.  After all, relative path resolution and URL
resolution are essentially similar.

Shawn Rutledge (14 September 2021 09:12) replied:
> We’re talking about potentially a lot of Image items though, Loaders,
> anything else that has a source url and gets used in a component which
> is instantiated in multiple contexts.  If it looks like a path, it’s
> actually a URL.  If it’s relative and Qt gets the base wrong, you need
> to worry about it.  When 6.2 LTS comes out, we’re guessing a lot of
> apps will be ported, and this will come up a lot.  It might cause some
> noise in Jira with the same bug report being written repeatedly: image
> doesn’t load, no idea why, it worked in Qt 5, blah blah.  Even if they
> understand, they will be unhappy having to write this boilerplate
> Qt.resolvedUrl() all over, and still complain that Qt 5 worked better.
> But if we make a syntactic improvement: before you had to write
> Qt.resolvedUrl() and now you write something simpler, maybe that will
> ease the pain a bit?

If someone has to edit all the same lines, does it really make that big
a difference that the edit is a one-character insert or wrapping a
string literal or url-or-string-valued expression in a function call ?
Particularly given a half-way decent refactoring tool ...

>> I don't see what's inherently wrong with a plain function like
>> Qt.resolvedUrl. It's very obvious - it says what it does on the tin.
>> Names are good that way.
>>
>> @ on the other hand would be completely opaque to a newcomer.

I must confess I find those persuasive points.
And Qt makes plenty of other sacrifices of brevity for clarity.

> Yep.  But Qt.anything() is also weird IMO: there’s no reason why the
> object containing this function should be called Qt.

Let me give you a reason - Qt is the implementor of the JS engine.
Specifically, the ECMA 262 spec's section on its *very* limited support
for URI-related functions [0] says (inter alia):

  The ECMAScript language itself does not provide any support for using
  URIs except for functions that encode and decode URIs as described in
  19.2.6.2, 19.2.6.3, 19.2.6.4 and 19.2.6.5

      NOTE Many implementations of ECMAScript provide additional
      functions and methods that manipulate web pages; these functions
      are beyond the scope of this standard.

As Qt's V4 engine is QML's implementation of ECMAScript, the resolver
function is an extension to the standard and should therefore be
accessed by an overtly implementation-specific namespace.

[0] https://tc39.es/ecma262/#sec-uri-handling-functions

> So maybe we need a function with a short name, not in a namespace?

A function without the Qt prefix is implicitly a member of the ES global
object and, as such, a "departure from" ES 262.  Code written apparently
in JavaScript but exercising extensions provided by a particular
implementation *should* make those extensions overt, if only so that
someone trying to reuse that code in real JavaScript knows what they're
going to have to adapt to the differences between implementations.

That said, I do think there might be value to talking to the ES 262
committee about adding resolveURI() to the suite of URI-related
functions that they provide, since it is surely one of the things that
all the "implementations of ECMAScript" do provide, one way or another.
All the same, until ES 262 includes it, please let's *not* add it to the
global object of V4, if only to avoid being stuck with a compatibility
problem when ES 262 does grow such a function.

> Or in some object that actually makes sense?  Or the suffix solution,
> because if we add units later, that will start to look like the same
> sort of thing even if it’s actually a bit different.

Having syntax incompatible with ECMA 262 is a matter to approach with
great care.  It will seem weird to those coming from JavaScript to write
UIs using QML, which I understand to be A Major Goal of QML.

> Or a function on the string: Image { source: “my
> icon.png”.resolvedUrl() }.

Again, extending the String type's prototype is a "departure from" ES
262 and I would counsel against it.  Anything that's an extension to the
base language *should* be packaged in a way that makes clear that it
*is* an extension specific to QML.

> But I’m just brainstorming without the implementation perspective in
> mind.

and I'm admittedly being rather conservative ;^>

I worked on a web browser for a decade and one of the things that left
me *very* aware of was the *huge* disservice that was done to authors of
web-pages and users of scripting-enabled browsers by the vendors who
used wilful incompatibility as a weapon in the browser wars.  Stick to
the standard and make any departures abundantly clear, so that readers
of code written using them have a clear and immediate indication that
what they're looking at *is* an extension.

>> or maybe put it inside the string as "csd:foo.png", and let the
>> question of syntactic sugar stew a bit?

> That’s an interesting idea, but then csd: starts to look like a new
> URL protocol alongside http: and file: and qrc:, right?  Don't we need
> another one for the directory in which the leaf component
> instantiation was done, rather than the directory in which the
> component exists?

yeah - we already have one pseudo-scheme, qrc:, let's not go wild on
others.  In any case, such a prefix approach would only work for string
literals, and I believe the issue here is to make this work for
arbitrary expressions, not just literals.  Once you get to writing
"csd:" + ... you're not really better off than calling a function in the
Qt namespace.

I think it is best to stick with "if it extends the ECMAScript language
it should be on the Qt object" - but perhaps I am being too
conservative, ...

	Eddy.