>
> Den 01-05-2012 10:45, André Somers skrev:
> > My gut feeling is, that += is just wrong in terms of declarative
> > programming. It has a destinctive imparative feel to it.
>
Bo Thorsen respondeth:
> That was *exactly* my instant reaction. And here's the reason (I think):
>
> The idea with the bindings is that they automatically update to whatever
> the targets are. So doing this:
>
> p1: p2 + p3
>
> is fine. Now, if you do this instead:
>
> p1 += p2
>
> Or if you convert it:
>
> p1: p1 + p2
>
> What does that mean? Should p1 add p2 everytime p2 changes? What would
> the base value be? And you can go on with the questions. I can't see a
> single good definition of this in declarative code.
>
> += doesn't make any sense here. It's for the javascript code only.
>
I don't dispute either of you -- I'd *really* like to say "declarative".
IMHO, the "parent-accumulates-children" is elegant, because a child
specifies/binds its parent, and there is only one. That seems nicely
declarative.
>From the other direction, of course, (parent-takes-ownership-of-child), it
must be done in Javascript. It would be nice if there were an alternative,
but ok, it works.
Logically, I'm looking for that solution: Many-to-many, establishing the
relationship from the "parent" side. I see your point that "accumulators"
sound "imperative", but I'm merely trying to declare-an-accumulation (like
we did with parent-has-children). The "+=" syntax is unfortunate, since it
"looks-like" an imperative operation.
Related issue (I think) is the sometimes-ambiguous "assign" or "binding":
Item {
some_val: parent.some_val; // binding to parent
some_val2: 10; // assign value (not bind)
some_val3: parent.some_val3; // would like to "assign", not bind, how?
}
ISSUE: Part of me likes the "simplicity" of QML, where ":" is "overloaded"
to both establish *bindings* and *values* (i.e., "not-bindings"). However,
I LOUDLY applaud the type-safety for QML properties, which places more work
on the developer (but the language/compiler helps watch-your-back for your
design decisions).
So, in a parallel universe, I would propose something like:
//NOT LEGAL QML, IS CONCEPT...
Item {
some_val0 : some_bound_value; // compile error if can't be bound
some_val1 | some_assigned_value; // assigns, never binds
some_val2 :: some_accumulated; // Always accumulates (never clears
previous)
}
I'm not proposing a new syntax, but rather, I see those as *three* distinct
operations that are truly "first-order". I'm not sure what would be a good
syntax. I fear "too-many-operators" would look terrible, and defeat the
purpose of QML simplicity.
So, if *instead*, we assume the ":" must be overloaded for all three
scenarios (it is currently overloaded for two scenarios), we could apply
attributes to the *target*, similar to C/C++:
int i, *p; // "p" is a pointer, the "*" applies to "p"
For QML, this would be:
//NOT LEGAL QML, IS CONCEPT...
Item {
some_val : some_bound_value; // binding established
some_val2 : ~some_bound_value; // "~" breaks binding, assigns value
some_val3 : -some_value_removed; // "-" removes-from-bound-set
some_val4 : +some_added_value; // "+" accumulates/adds-to-bound-set
}
This would work, and is consistent with the current QML syntax.
As a further aside, I've already found cases where I could use the "~"
thing, where I wanted to "break-binding" (did not want binding
established). We do not *always* want bindings, because those sometimes
establish circular dependencies, and no, the "update-engine"
does-not-and-cannot update through the bound values in those cases,
although it looks like it should (this is not a rare problem).
Thoughts?
--charley
_______________________________________________
Qt-qml mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt-qml
