Hi Charley,
Den 01-05-2012 13:58, Charley Bay skrev:
> 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?
> }
Item {
id: thisIsParent
Item {
property int some_val3
Component.onCompleted: some_val3 = thisIsParent.something
}
}
Maybe not elegant, but I don't like bloating syntax with something that
can fairly easy be described in legal code.
> 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).
I won't argue against those, other than say that you need to come up
with a lot of good usecases for them.
You can already do all this in javascript, and I really don't like the
idea of adding to the language, unless it's something that can be used
in many different situations.
You haven't convinced me of the reason for it, but I'm not saying it's
impossible to find enough reasons to get it in.
Bo Thorsen,
Fionia Software.
--
Expert Qt and C++ developer for hire
Contact me if you need expert Qt help
http://www.fioniasoftware.dk
_______________________________________________
Qt-qml mailing list
Qt-qml@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-qml
