On Mon, 30 Apr 2012 10:56:58 ext Charley Bay wrote:
> > In addition to "bindings" and "assignment" (possibly including
> > single-values or lists-of-values), is there a QML concept of
> > "plus-equals"?
> >
> > For example:
> >
> > Item {
> >
> > my_set0 : some_val0; // replace value
> >
> > // ...can I "accumulate" values?
> > my_set1 :+ added_val; // Something like this?
> > my_set2 +: added_val; // Something like this?
> >
> > }
> >
> > Artem respondeth:
> >
> > Not in QML, but I you can implement it in JavaScript.
> > You can implement an OnChanged: handler for a property and whenever it is
> > changed add new value to some JavaScript list.
> > Certainly you'll have to care about when you try adding the same value
> > twice as that won't cause OnChange signal.
>
> The "OnNNN:" may be sufficient, but I was hoping for something more
> elegant.
>
> What I am curious about is why you need such an accumulative property. Why
>
> > can't some addValue() javascript function suite you?
>
> I *really* want to stay as "declarative/direct" as possible (not drop to
> "imperative-Javascript" unless absolutely necessary, which seems quite
> "indirect"). For example, the "OnNNN:" syntax seems a little "indirect"
> and "unwieldy" when I merely want to "declare-an-accumulation".
onNNN is almost imperative, because you're stepping through the program flow
(but it is still described in a declarative form here). The concept of
declarative, where you set up everything in advance, and order doesn't matter,
doesn't mesh well with accumulation. This is because accumulation requires
adding to the value at a specific point, otherwise it's an infinite loop.
Events provide specific points, if you don't want to use them you'll need to
suggest another 'specific point' in order of this to work conceptually.
> The *concept* is interesting: An item implicitly "grows" its list of
> "children" (when the children "declare" their "parent"). I like that. I
> want more like that. However, that works because the "one-to-many" is
> *implied* (you can say, "That's-my-parent!", and the parent
> "takes-ownership"). That won't work for "many-to-many" relationships, or
> when you must specify the other-way-around (e.g,
> "I-accept/take-that-item"), and that's a really common pattern/problem.
That works because it's an implementation detail behind the scenes in
imperative C++. This is why we don't like people touching the children list in
QML ;) . Normally, this sort of usecase fits more naturally to an imperative
flow and I just accept that.
> An example use would be the QML-description for the QBS build definition.
> I find the "describe-lists-of-files" quite awkward (e.g., "a-little-off").
> We *must* be able to declare *partial-sets* of things, with the
> understanding that those sets will be *grown/adjusted* later. It seems so
> fundamental to me, and I see "go-to-Javascript" as the "goto-last-resort"
> only when you have no other choice.
>
> For this, "Make" and shells and pretty much all interpreted languages have
> some kind of "+=", and it would-be-nice to have something "LISP-ish" like
> "declare-these-as-appended-to-the-existing".
Those are interpreted imperative languages, correct? Make is a lot closer
though, not that I've seen += in it before ;) . Possibly what you want is the
ability to append to the base value of a component, similar to how a make file
adds to existing env variables?
e.g:
Alpha.qml
QtObject {
property list<real> nums: [1,2,3]
}
Beta.qml
Alpha {
nums: Alpha.nums + [4,5,6] //giving [1...6]
}
Gamma.qml
Alpha {
nums: [4,5,6] //giving [4...6], overwriting base value
}
--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks
_______________________________________________
Qt-qml mailing list
Qt-qml@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-qml
