[Development] Deprecating modules with 5.5

[Simon Hausmann]

On Thursday 5. February 2015 23.08.03 Jaroslaw Staniek wrote:
> On 5 February 2015 at 16:44, Simon Hausmann
> 
> <simon.hausmann at theqtcompany.com> wrote:
> > On Thursday 5. February 2015 16.32.08 Jaroslaw Staniek wrote:
> >> On 3 February 2015 at 09:50, Hausmann Simon
> >> 
> >> <Simon.Hausmann at theqtcompany.com> wrote:
> >> > Hi,
> >> > 
> >> > Functionality wise, what type of "class" do you wrap with QScriptClass?
> >> 
> >> Examples (you can guess from what project by looking at my footer):
> >> - Light data types (anything you see in databases and isn't mapping to
> >> javascript types). Long long?
> >> - Any very numerious non-QObject objects or calculated entities and/or
> >> properties that have no their structures at all. Thing about a
> >> database record  accessible by record.<fieldname>.
> > 
> > For those, would the new value type bindings be a sufficient replacement?
> > See also
> > 
> > http://doc-snapshot.qt-project.org/qt5-dev/qtqml-cppintegration-data.html#
> > value-types
> > 
> > Once your type is a Q_GADGET you should be able to make a copy of it
> > visible in JavaScript as easy as
> > 
> > QJSValue value = engine.toScriptValue(myValueType);
> 
> Thanks, I'll analyze that. Quick look make me unsure about one thing,
> Q_PROPERTY is a compile-time declaration. I'd like to add
> properties/members dynamically at run time and I'd like to of course
> avoid calling eval() for that.

Hmm, we currently only allow that for QObject bindings. So if you do

QJSValue wrapper = engine.newQObject(someQObject);

then you can add arbitrary properties to that JS object simply via

wrapper.setProperty("myExtraProperty", 42);

and it will be a dynamically added property if there exists no Q_PROPERTY.

The value of that property is accessible from C++ via the QJSValue API, i.e. 
if you have a pointer to the QObject you can do

QObject *thatObject = ...
QJSEngine *engine = qjsEngine(thatObject);
QJSValue blah = engine->newQObject(thatObject).property("myExtraProperty");


In theory we could add the same feature to the value types, but I'm hesitant 
about it. With QObject the ownership semantics are explicitly shared, so it's 
clear (after learning the API) that you're operating on an object shared 
between C++ and JavaScript. With value types the engine will take a copy of 
the data when you do engine->toScriptValue(something) so it's not clear what 
should happen with those "dynamically" added properties when going back to 
C++.

So if you can apply the use of dynamic properties to QObject based types, then 
I think you should be good to go.


Simon