Review Request 118575: QML components can only see the declarations of their base classes and in the top-level context, not their parents
Milian Wolff
mail at milianw.de
Fri Jun 6 16:29:22 UTC 2014
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118575/#review59463
-----------------------------------------------------------
Hmmm I do not understand this patch. This works just fine:
import QtQuick 2.0
Item {
property string foo: "Hello"
Item {
Component.onCompleted: {
console.log(foo);
bar();
}
function bar() {
console.log(foo);
}
}
}
It looks to me as if you implemented something that does not actually follow QtQuick2 behavior?!
- Milian Wolff
On June 6, 2014, 9:37 a.m., Denis Steckelmacher wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118575/
> -----------------------------------------------------------
>
> (Updated June 6, 2014, 9:37 a.m.)
>
>
> Review request for KDevelop.
>
>
> Repository: kdev-qmljs
>
>
> Description
> -------
>
> QML has very strange visibility rules. Here is an example:
>
> import QtQuick.Controls 1.1
>
> Label {
> id: label
> text: "Hello"
>
> Button {
> id: button
> onClick: { label.hello = "World"; }
> }
> }
>
> "button" is an object that is declared inside label, and thus has an inner context that is a child of the context of "label". However, "button" cannot see the "text" property of "label", even if this property is declared in a parent context. "button" can see "label", though, as "label" is declared in the top-level context (using Declaration::setContext, this was already the case without this patch).
>
> The inner context of a QML object therefore must be able to see the top-level context, its imported parent contexts (class inheritance), but not its parent context. This patch handles that by introducing QmlDUContext, a subclass of DUContext. QmlDUContext provides a method that allows DeclarationBuilder to specify that a context should be blind to its parent (but not the top-level context, hence the addImportedParentContext(topContext()) call).
>
>
> Diffs
> -----
>
> codecompletion/tests/qmlcompletiontest.cpp c029ea9
> duchain/CMakeLists.txt b02a257
> duchain/declarationbuilder.h 1e6c895
> duchain/declarationbuilder.cpp ede6407
> duchain/qmlducontext.h PRE-CREATION
> duchain/qmlducontext.cpp PRE-CREATION
> tests/files/test.qml cbe2fa6
>
> Diff: https://git.reviewboard.kde.org/r/118575/diff/
>
>
> Testing
> -------
>
> Two new unit tests have been added. The first one ensures that the code-completion doesn't list symbols that should not be visible, and the second one checks that UseBuilder does not see uses where there shouldn't be any.
>
> All the other unit tests still pass, but I'm not very confident of the implementation of QmlDUContext. There were many things to take into consideration, many constructors to implement, a macro that mustn't be forgotten, special setClassId calls, etc. I hope that I haven't missed anything, but I'm not sure (valgrind doesn't complain about anything, though, but I'm afraid of subtle cache-related bugs). No other language support plugin that I know (kdev-clang, kdev-oldcpp, kdev-python, kdev-ruby) subclasses DUContextData (they subclass DUContext, though), so I had no example.
>
>
> Thanks,
>
> Denis Steckelmacher
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20140606/9b6e0be9/attachment.html>
More information about the KDevelop-devel
mailing list