> On 2021 Sep 9, at 17:32, Ulf Hermann <ulf.herm...@qt.io> wrote:
>
> A user can fix this by explicitly calling Qt.resolvedUrl() in order to
> resolve the URL in a specific context and make it absolute. As we need URLs
> rather often in QML, we will see much more Qt.resolvedUrl() in Qt6 than we
> have seen in Qt5. As Qt.resolvedUrl() is quite a mouthful, there should be a
> shorthand for it: the '@' operator.
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?
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?
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?
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?
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.
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.
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).
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
