[Development] Container refactor update

[Rene Jensen]

On Mon, Jun 18, 2012 at 11:58 PM, Thiago Macieira <thiago.macieira at intel.com
> wrote:

> Here's the current status of my endeavour:
>
>
Hi Thiago.

As you may have figured out by now, I am one of those who plea for an extra
set of container widgets deriving from QObject. You know, so they can
support slots and signals. But seeing how hard people work to get
performance out of the core containers, I guess it will never happen.
Yes, of course, it comes from some bad experiences I had learning how to
expose QLists to QML. But the discussion is universal in the Qt universe.

Is this crazy talk? I would imagine that given a set of containers like ...
hmm ... QSmartList, QSmartMap, QSmartHash inheriting from QObject (yes, I
know ... moc and templates bla bla - I could live with fixed
key/value-types if that's what it takes - java did before going
parametric), that us poor programmers would not have to work so hard to
keep complicated interconnected data objects synchronized between the UI
and e.g. a database or over a network wire.

I mean.. SIGNAL(itemAdded) would be nice from time to time. Am I alone in
this?

What would it take? No clue. I'm sure you all have thought immensely about
this before. One simple guess: All methods on a QList needs to check
quickly if this is a "monitored" list when changing it. If so, those
methods could notify their depending QObject monitor ("QSmartList") which
then emitted the signal.

Then again, I can easily be convinced that the current approach is better.
I wouldn't suggest wrapping plain ol' datatypes inside QObjects for simple
Q_PROPERTIES, so why lists and maps?

Best regards,
Rene Jensen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120619/2e78e902/attachment.html>