Guaranteed Property order?
-
I am doing some work with Qt Properties and have found that they are solving a particular problem I have very well. I do have one concern, though, as follows.
Experimentally, it seems that Properties are given to you (via QMetaObject) in the order in which you define them in a class. This holds true in subclassing as well - first you get the base classes properties, then you get yours, in the order you defined them. My question is this: is the order you get these back guaranteed? I'm writing some code that relies on the order the Properties are defined and I don't see anywhere in the documentation that this order is guaranteed. This leads one to worry that a future revision of Qt might break one's code because perhaps they decide to return properties in some other order.
If this is a guaranteed functionality, I humbly suggest the documentation be updated to say so. If it isn't, I would strongly advocate a discussion around this topic.
-
Hi,
I'm sure it is not guaranteed. Currently, it is build by moc, which scans a header file and fills some _moc.cpp file. But why is the order important for you?
-
I knew that someone was going to ask.... should've just explained in the OP. I am using properties to define messages which go out over a network. Then, I can generically parse a class by pulling off it's properties (IN ORDER!), byte swap, and shove it out an ethernet connection. I can also then go and iterate over said class and create an input GUI based on it's properties.
The key is that I can get type info about a Property, and order is critical. I would like to see this added as a requirement on Qt (both the libraries and tools).
-
I don't think that this will be added as a guaranteed order in Qt. Would it work for you to just serialize the properties in alfabethical order instead?
-
[quote author="Andre" date="1327934044"]I don't think that this will be added as a guaranteed order in Qt. Would it work for you to just serialize the properties in alfabethical order instead?[/quote]
That would also be my approach. IIRC it is possible to get the props per class (base class) so that could also be regarded, or just sort them.
-
I too think that the property order will not be guaranteed at any time now or in the future. There isn't even a purpose of doing so. For making your network protocol reliable, you seriously should consider a more robust data exchange format which includes the property name plus its data. Using [[Doc:QDataStream]] will disburden you from swapping bytes manually.
-
Alphabetical doesn't work for me. The order is very specific, and makes sense in terms of sending commands over the wire between two pieces of software. Besides, if they were just alphabetical, my GUIs wouldn't make any sense.
I'm not sure why it is a problem having this order be defined as "the way" Qt does things.
-
Wow, it is too bad that no one is even considering what I'm saying... I've implemented various solutions to this problem, and it turns out that this property solution is the perfect answer to my problems.
It is a question of right sizing - I don't NEED a more robust protocol. Doing this this way with Qt properties does what I NEED and nothing more. It is the perfect trade of complexity/functionality. Also, I may not be able to use QDataStreams because my data needs to be transmitted over a weird protocol, not anything Qt knows about (I need to shove the bytes out through a library onto a proprietary system).
But the whole thing does key on Qt giving me the properties back in the order in which I defined them. The bottom line probably is this - as much push back as I'm getting, this will probably never change simply because there is no reason to change it. And if it ever did, I could always add a feature request to have an option where QMetaObject gave you properties in the order in which they were defined.
-
[quote author="medvedm" date="1327937975"]Wow, it is too bad that no one is even considering what I'm saying... [/quote]
Why? We just said, we think this makes no sense as there is no guarantee. And we gave some proposals, how to solve it.
[quote author="medvedm" date="1327937975"]But the whole thing does key on Qt giving me the properties back in the order in which I defined them. The bottom line probably is this - as much push back as I'm getting, this will probably never change simply because there is no reason to change it. And if it ever did, I could always add a feature request to have an option where QMetaObject gave you properties in the order in which they were defined.[/quote]
I don't think that will be done ever. The property system is internal stuff and it can be queried. Why should any order be defined? Only because one user would need it? The I have a bunch of features that MUST be added, as I know at least two users that need them :-)
-
Well, if you don't need a more robust protocol, then go ahead and trust what you get, and hope it won't break in a future Qt version. Nobody is stopping you, we're just telling you that you cannot rely on the order to stay consistent.
You cannot judge if there is no reason to change it in the future. It may be that the way properties work internally will be changed in the future. In such a change, which may have very sound reasons, the order in which properties are returned may not be preserved. Perhaps at the moment a list is used, while in the future a QHash may be used, for instance. As long as no promises are done to preserve the current order, this can be changed. The binary compatibility constraints are already quite heavy, I don't think they should be made even heavier by making promisses like these.
-
If you look at how properties are returned, it is clear the concept of order is already there. You deal with properties via QMetaObject, which has the propertyOffset() function. This function is where in the set of properties your current class' properties start. All other properties from 0 - propertyOffset() are base class properties. So already we have order implied. This could not be changed without breaking older code.
I guess what I'm saying is that the notion that there is absolutely no order to properties for a QMetaObject is wrong. You are gauranteed that the lower properties are base class and upper properties are sub class. It is already implemented to return the properties in the order that they are defined anyways, so obviously this is what makes the most sense.
-
I am not saying that there is no order, I am saying that you cannot rely on that order to stay stable in future releases. However, like I said above, if you feel confident, you may use the order you get now. Just don't come complaining if some future release breaks your assumptions.
-
[quote author="medvedm" date="1327948480"]If you look at how properties are returned, it is clear the concept of order is already there. You deal with properties via QMetaObject, which has the propertyOffset() function. This function is where in the set of properties your current class' properties start. All other properties from 0 - propertyOffset() are base class properties. So already we have order implied. This could not be changed without breaking older code. [/quote]
This just implies that base class properties have lower numbers.
but the order of your classes members might change without breaking this logic.