[Qtscript-bindings] Inheritance question (why call the parent constructor twice?)
Thiago Silva
tsilva at sourcecraft.info
Wed Jul 22 19:12:24 CEST 2009
Hello Kent,
thanks for commenting.
(seems gmail didn't reply to the list...sorry)
On Tue, Jul 21, 2009 at 6:19 AM, Kent Hansen<khansen at trolltech.com> wrote:
> If "editor" is not meant to be instantiated for the purpose of
> instantiation ( :-) ), but rather only to set up a prototype chain (just
> one of JS's quirks; see e.g.
> http://javascript.crockford.com/prototypal.html), you don't need the
> QTextEdit.call() in that constructor. It can just be a plain object. The
> point of the QTextEdit.call() is to work around JavaScript's inability
> to let you "subclass" native objects. It changes the [[Class]] property
> of the this-object so it becomes a QObject wrapper, and actually
> instantiates the C++ object that the script object wraps.
>
>
yep, I noticed that.
>> A related problem is dealing with inheritance of
>> properties: the QTextEdit.call(this) call brings all the QTextEdit
>> properties directly to the "x" object, shadowing properties with the
>> same name in the chain (which is odd, since QTextEdit is ancestor;
>> it's properties that should be shadowed).
>>
>
> Right, methods that are handled by QtScript's dynamic QObject binding
> will override the generated bindings and classes based on them; see
> http://www.qtsoftware.com/developer/task-tracker/index_html?method=entry&id=245820.
> If that suggestion is implemented, the dynamic+generated bindings can
> play more nicely together.
>
interesting
>> Anyway, such code is necessary because, for every method call, the
>> binding classes try to extract the c++ object from the "this" js
>> object ignoring it's prototype chain.
>
> The prototype chain is not ignored; but just because an object in the
> prototype chain is of a certain type doesn't mean that the this-object
> itself is of that type, from the C++ side of things. For the bindings to
> make sense, we _need_ to extract a corresponding C++ object from the JS
> this-object.
>
yes, while I certainly understand the need to extract the
corresponding c++ object, I don't understand why not lookup for it in
the prototype chain of the this-object too. That would make more sense
to me when thinking about property lookup / method dispatch.
> Yes, from JS semantics it passes as a QWidget; the issue is the C++
> side. When you call w.show(), what C++ object does it call show() on? Do
> you dynamically create a C++ object of the proper type the first time
> someone attempts to access a QObject-inherited property in w? That would
> work, I guess. It still doesn't change the point: There needs to be a
> corresponding object that represents w in the C++ world; and that object
> needs to know about the JS object, so that it can propagate calls from
> the C++ world back to JS (this is what the generated qtscriptshell_*
> classes do).
>
to better illustrate, I've setup a gitorious clone here:
http://gitorious.org/~tsilva/qt-labs/tsilva-clone
this last commit shows what I've done:
http://qt.gitorious.org/~tsilva/qt-labs/tsilva-clone/commit/e63ecdee6a48eacf0afc6d76a0fedc0dcacc4a1d
I haven't put a lot of thinking in it, as it is fulfilling my needs so
far. But it shows what I've talked about.
Cheers,
--
Thiago Silva
Computer Science
M.Sc. Candidate at Federal University of Pernambuco
jabber/gtalk: tsilva at jabber-br.org
http://blog.sourcecraft.info
More information about the Qtscript-bindings
mailing list