I see.  So something like this:

QObject* QJSEngine::jsValueToQObject(const QJSValue & v);

Introspects the functions and properties and creates a proper
QMetaObject.  I might take a stab at this if I have time.

On Wed, Feb 11, 2015 at 10:50 AM, Hausmann Simon
<[email protected]> wrote:
> Hi,
>
> The brute force way is to add this feature to the engine at the expense of 
> performance, memory consumption and maintenance :)
>
> Today you can invoke Javascript defined functions by simply getting the 
> function as a property via QJSValue and call() it.
>
>
> Simon
>
>   Original Message
> From: Rees, Kevron
> Sent: Wednesday, February 11, 2015 17:18
> To: Hausmann Simon
> Cc: Thiago Macieira; [email protected]
> Subject: Re: [Development] why is QJSEngine not modifying metaObject
>
>
> On Wed, Feb 11, 2015 at 12:03 AM, Hausmann Simon
> <[email protected]> wrote:
>> Hi,
>>
>> Kind of :) It works on a type level. So a new type is defined with new 
>> methods and a new meta object is defined. But it doesn't use a mechanism 
>> where a new meta object is created each time a method is added.
>>
>> If we move the current engine over to generate meta objects from internal 
>> classes then perhaps we could create the meta objects on demand and batch 
>> them. That would make the example at hand work.
>>
>
> This sounds desirable.
>
>> Of course this could also be implemented by brute force, but I'm not sure it 
>> is worth it.
>>
>
> Can you elaborate on this brute force method?  Is there another way to
> get the internal JS class metadata in c++?
>
>> Simon
>>
>>   Original Message
>> From: Thiago Macieira
>> Sent: Wednesday, February 11, 2015 08:35
>> To: [email protected]
>> Subject: Re: [Development] why is QJSEngine not modifying metaObject
>>
>>
>> On Wednesday 11 February 2015 07:11:26 Hausmann Simon wrote:
>>> Hi,
>>>
>>> The short answer to your question is that the meta object system isn't
>>> really designed for this. In theory this could be implemented but it would
>>> come at a high cost for something that rarely happens. The qml engine
>>> supports this, but in qml this happens at type compilation time, not fully
>>> dynamic.
>>
>> Wasn't this how QML1 worked?
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>   Software Architect - Intel Open Source Technology Center
>>
>> _______________________________________________
>> Development mailing list
>> [email protected]
>> http://lists.qt-project.org/mailman/listinfo/development
>> _______________________________________________
>> Development mailing list
>> [email protected]
>> http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to