I'm not talking about coding space as much as I'm saying that trying to duplicate an existing data structure is bad coding.

What is the mechenism that will store your list? Who keeps track of it? How will it know when to update? As an example, if you inherit from qgraphicsitem and put code in the constructor to append to a master list, then all your objects that are derived from this subbed class will be auto add to the list (a la autolist pattern). This works well, except now look at how an undo/redo framework might be adding removing objects from the scene. In my case the object isn't destoryed and recreated, the pointer to the object is held by the undo framework while the object is removed from the scene list. This will not cause your list to be properly updated so you will need to modify this list now from your undo/redo statements.

What if you wan't to add a generic object? You won't have the convenience of the autolist pattern, so you'd have to do the tracking somewhere higher up. Now you can see how the code to track objects starts sprawling throught the code.

Imagine creating and destorying hundreds of objects at a time in a scene and keeping a list of them. If you had a bug anywhere this list would become out of sync, but might go unoticed in a subtle way becoming a typical "software bug".

This is why I feel that using the built in accesor methods is the better choice for now. The problem then becomes in the optimization of that. Clearly you can see how its not efficient to get a list of all objects just to only use a few of them.

I'm saying that as Graphics View matures, one of the important features it might look at is the power of other Scene Graphing software. They let you do optimized selections to improve the speed/reliability rather then forcing others to reduplicate structures elsewhere. This seems fundamental in order to improve the capabilities of Qt and to improve upon thier great framework.