My first impression is that this looks like nice syntax. However maybe we
should discuss a bit how it fits into the language design, since it seems like
we’re trying to have a cohesive language design nowadays. I’m never quite sure
to what extent QML is “our” language, or to what extent the rule is “just do
what Javascript does”, and then we have to defer to ECMA standards, and common
web-development practices (which I don’t know very much about). But is there
any precedent for this “@“ operator, for what it’s worth?
We've extended the JavaScript syntax in quite a few ways already. We
have type annotations borrowed from TypeScript, and an "as" keyword with
our own semantics. Adding additional constructs that don't clash with
JavaScript is fine.
QML has this peculiarity of doing string conversion when binding to properties
of specific types, like color: “#123” and point: “5,6” and vector3Prop:
“5,6,7”. Personally I prefer languages in which the syntax for type conversion
is definable and extensible rather than being just a side effect of trying to
shoehorn a string into some other type; but that’s what we have. And another
peculiarity is putting all those constructor functions into the Qt namespace,
like Qt.rgba(), Qt.point(), Qt.vector3d() etc. (This is probably even less
intuitive for JS developers?) If we were trying to design a language from
scratch, without the baggage left from Qt 4, we’d probably be able to do better
with the syntax for both of those, right? But can we evolve toward something
better now?
Creation of value value types from JavaScript is indeed still an open
problem. I don't think we will need an extra operator to fix it, though.
You should just be able to pass the parameters to a value type
constructor as a JavaScript array or object. For example:
property point p: [5, 6]
property point p: {x: 5, y: 6}
In order to make this perform, we need some kind of typed JavaScript
"parameter object" that lives on the stack as far as possible while
adhering to reference semantics. We want such a thing anyway, for
compilation to C++. The specifics are not decided, yet. If you have any
particular ideas, let me know.
So now it seems like you are introducing a prefix operator on that
string-shoehorning, which could potentially become a multi-purpose feature. It
causes a bit of bias that this operator is pronounced “at”, so maybe the
thought is it fits better with the sorts of conversions that imply some sense
of “place”, either a geometric location or in a virtual space like the space of
URLs and URIs?
Yes, introducing an entirely new operator for the specific purpose of
URL conversion and resolution seems rather excessive at first. However,
URLs are a vital thing in QML, and the automatic string-shoehorning is
indeed not ideal. In order to make the conversion explicit, you have to
write Qt.resolvedUrl() today. No one wants to do that in all the places
where they use URLs. We still should make the conversion explicit, in
order to avoid all the ambiguity surrounding strings and URLs, as seen
in the various bugs. Instead of an operator, we could introduce a new
function in the global object, e.g. qsUrl(). However, this potentially
clashes with other names and is not that much nicer than
Qt.resolvedUrl(). Also, it doesn't express "resolved" (and I want a
non-resolving URL constructor, too). The '@' operator is nice in that it
can be easily thought of as resolving the "place" it points to and it
doesn't require parentheses.
However, if we nail down the meaning of @"string" to "create and resolve
a URL", then we cannot use a plain '@' for much else. We might, however,
add, for example, a @point[32, 34] that would create a point and resolve
it in some way. The plain '@' would then become a shorthand for @url.
URL is certainly the most important value type that isn't also a
JavaScript type. Therefore, the extra short syntax seems adequate to me.
(This brings up the point that I should check for @somevariable to be
invalid ... there you do need to add parentheses or a space)
We already have some string conversions in place, but if we define “@“ as
giving that conversion some sort of “alternate” interpretation, in how many
more contexts does that idea make sense? Do we need an “alternate” way of
converting colors, points, rectangles or something like that? Or could the “@“
operator be even more general than that, sometimes being applied to other types
than strings? Maybe to convert Euler angles to a quaternion? Radians to
degrees?
In the above sense, the '@' operator should only be used for things that
perform some resolution. I could, for example, envision geometry mapped
to/from the surrounding element. An object type like QQuickItem might
define '@' operations for specific value types which would then be valid
in its scope.
If we use the “@“ operator for this-and-that over time, it would still be best
if it retains some sort of language-wide cohesive meaning. On the other hand,
it seems a waste to introduce a nice single-character operator and only ever
use it for _one_ purpose; of course that’s fine for a range of minor versions
if it only does one thing, as long as we know how we can potentially go further
with it.
URLs are actually rather important. You use them to identify JavaScript
and QML files, and any resources you refer to. Even a separate operator
only for URLs would be fine for me.
Oh I just got another idea… if we had introduced units into QML (which we IMO should
have), as in being able to specify Rectangle { width: 5mm }, we could think of URL
resolution as another type of unit conversion; so then I suppose it should be some
sort of postfix operator rather than prefix, like maybe Image { source: “my
icon.png”csd } (if we define “csd” as meaning “component source directory”). Using
short words rather than punctuation would leave it more open to having several more
such conversion operators rather than only one “alternate”. OTOH I think @“my
icon.png” looks nicer for this one usecase, considered alone. In C++ we have a
counter example with string-conversion tokens that are prefixes, as in u”string”.
And the even weirder ones with extra stuff on both ends, as in u"qtbase”_qs.
This only works for literals. You can resolve any expression as URL,
though, as long as it evaluates to a string or a URL. We might still
introduce units for literals and there we might have a "url" suffix in
order to create a URL in the first place, rather than going through
string. It would not resolve the URL relative to the current context.
However, units are yet another discussion.
It’s just a question of which approach leads to more cohesion of the QML
language as a whole, and which way is most intuitive for users (those who have
mainly prior JS experience, and those who have Qt C++ experience).
Neither kind of experience helps you with URL resolution in QML,
unfortunately. In HTML a relative URL is always relative to the place
where it's used. You can pass relative URLs around all you like and they
might mean different things in different places. I've actually tried to
do this with the behavior change from Qt5 to Qt6, but we see now that
this is not quite enough.
So, the cohesion of the language is the actual question. The above
explanations make it clear, that the '@' operator still leaves enough
potential for extension while recognizing the central importance of the
url type and granting it a special shortcut.
best regards,
Ulf
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
