Remote Objects PROP does not support arbitrary function names

.rep file macro PROP(<type> myProp READWRITE) expects the getter to be exactly signatured and called <type> myProp(), the setter to be signatured and called void setMyProp(<type>) and the notifier signal to be signatured and called void myPropChanged(<type>). This disallows the remoting of existing objects where these are not the exact names and signatures, requiring extensive refactoring. In fact, this is the case with all of the built-in QtQuick objects I've seen where notifiers of properties do not have an argument, making them essentially currently unusable in remoting.

I argue that .rep files are redundant and unnecessary, and all information required by repc is available in header files (with some basic macro extensions that should be built into Q_PROPERTY) and it should operate exactly as moc, but I also understand that this feature will never be removed in reality for whatever amount of backwards compatibility required of Remote Objects at this point. However, it is obvious that the minimum functionality required here is that PROP functions more like Q_PROPERTY, namely allowing arbitrary function names and signatures (as long as compatible to the degree allowed by Q_PROPERTY). However, when the .rep file DSL is extended to support these functionalities, they will look exactly like header files and become redundant.

A drastically better and more maintainable solution at this point would therefore be for repc to support parsing headers.