Increasing usage of references for non-value objects?
-
You are over engineering.
You don't need to reinvent the wheel. Just make your custom data class use implicit sharing as well. This way you can extract it from a variant cheaply (only a pointer is copied).Modifying the internal object from outside the model and then emitting the dataChanged manually is a hack and a breach of S.O.L.I.D
-
@elfring said in Increasing usage of references for non-value objects?:
how can you emit the "itemChanged()" signal?
I would use a simple function call for this purpose.
Are you looking for any other answer?I need you to think about it some more.
Imagine these methods become available in a future version of Qt:
QVariant& QStandardItem::dataRef(int role)void* QVariant::internalPointer()
These are the kinds of "extensions" that you wanted when you said "Increasing usage of references for non-value objects" right?
With these functions, are you sure you can modify the data inside a QStandardItem without copying anything AND emit the required signal? Write some example code to try it.
-
Imagine these methods become available in a future version of Qt:
I guess that they can become useful for protected member functions.
These are the kinds of "extensions" that you wanted when you said "Increasing usage of references for non-value objects" right?
These suggestions can eventually fit to my imaginations. The mapping of (internal) data to custom information might need C++ function templates.
…, are you sure you can modify the data inside a QStandardItem without copying anything AND emit the required signal?
I propose to distinguish better between efficient data access and signal transmission for the discussed use cases.
-
@elfring said in Increasing usage of references for non-value objects?:
- Programming interfaces which return pointers can be encapsulated so that null pointer checks will be performed at fewer source code places.
And factories to create those objects too, right? Sounds more like Java. There's no reason to throw abstractions over simple classes that don't need them. Factories for the sake of factories and interfaces for the sake of interfaces is what Java does, it's verbose and slow and gives you nothing in return. There's a factory here and there and an interface here and there in Qt, but where it is needed, not just for the sole purpose of implementing patterns. To finish that rant off - why do you want to force heap allocations onto me? I prefer and use the stack wherever possible as it's faster and safer, you now want me to
newevery single object I create?- Model adaptors
To what end? Adapters for what exactly? You have proxy models, and models are (almost) perfectly matched to the views' interfaces, so what is that you want an adapter for? ... and you can always write your own if you need it to match your own class' interfaces.
- Occasional Qt object construction without default parameters
Practically all Qt classes allow for default constructors. As for the default parameters themselves - it's just an implementation detail that's moot here.
If you have explicitly concrete examples of why any of the above is needed, I'm all ears, otherwise this is simply a theoretical debate with very little practical relevance.
-
…, you now want me to
newevery single object I create?No. - But a lot of objects are generated by this operator as usual.
You have proxy models, …
How do you think about a test case for the topic “Support for QStandardItem proxies?” then?
If you have explicitly concrete examples of why any of the above is needed, I'm all ears, …
Would you like to take another look at a feature request like “Support for object creation based on constructors with parameters without default values”?
-
@elfring said in Increasing usage of references for non-value objects?:
No.
Then don't.
- But a lot of objects are generated by this operator as usual.
I may usually drink coffee, but this doesn't mean I only drink coffee, does it?
How do you think about a test case for the topic “Support for QStandardItem proxies?” then?
Formally speaking the item delegates are already adapters, so I don't follow your point.
Would you like to take another look at a feature request like “Support for object creation based on constructors with parameters without default values”?
I have no idea why you want to force non-default-constructable objects to the designer. I see no gain in even trying to do such a thing, much less what would be the point of enforcing it ...
-
Formally speaking the item delegates are already adapters, so I don't follow your point.
Do you prefer to fiddle with delegates instead of adjusting data models by proxies (for simple displays)?
I have no idea why you want to force non-default-constructable objects to the designer.
Do you find any of the linked information helpful anyhow?
-
@elfring said in Increasing usage of references for non-value objects?:
Imagine these methods become available in a future version of Qt:
I guess that they can become useful for protected member functions.
...
These suggestions can eventually fit to my imaginations.
Question: Are these are the kinds of "extensions" that you wanted when you said "Increasing usage of references for non-value objects"? If not, then please write some example code to show us your proposal. Without this, it is very difficult to discuss things.
…, are you sure you can modify the data inside a QStandardItem without copying anything AND emit the required signal?
I propose to distinguish better between efficient data access and signal transmission for the discussed use cases.
You are asking for the API to be changed to increase efficiency, but you must also realize this change makes the API design less intuitive which increases the risk of errors. (see @VRonin's post: "Modifying the internal object from outside the model and then emitting the dataChanged manually is a hack and a breach of S.O.L.I.D" ) This is also considered premature optimization.
QStandardItemModel is a convenience class, so intuitive design is much more important than efficiency here.
