Review Request: Proposal how to fix a problem I have with ObjectTreeBuilder
Arjen Hiemstra
djfreestyler at gmail.com
Mon Dec 19 14:55:55 UTC 2011
> On Dec. 19, 2011, 1:10 p.m., Arjen Hiemstra wrote:
> > "This patch assumes that all objects in d->objects don't have any parents yet."
> >
> > This is partly correct - all items that are in d->objects do not have parents since they are considered to be top level items.
> >
> > They do have children, however, which means the current code breaks any reference lookup in children that should not be done
> > from the project. The reason it does work for Invaders is because d->project is set to the first top level item encountered when
> > no explicit project is passed in ObjectTreeBuilder's constructor. Thus, the second code path is triggered which successfully finds
> > the object. Maybe you can explain the problem in a bit more detail so we can come up with a solution?
>
> Felix Rohrbach wrote:
> My achievements are in a separate file (lets say "project/assets/AchievementsAsset"). Let's say there are two Achievements in this file, Achievement1 and Achievement2. Achievement2 has a reference to Achievement1. In ObjectTreeBuilder::visitStart, the path of that reference (ref.path) is "project/assets/AchievementAsset/Achievement1". Achievement1->fullyQualifiedName() is "Achievement1", as it isn't in the project tree yet. Now if you call Achievement1->findGlobalObjectByName( ref.path ) it will return a 0-pointer, as it can't find that path, but it should return a pointer to itself.
>
> Do you have an idea how to solve that?
One solution is to pass a parent to the parsing methods. The reason I did not add this yet is because I wanted to avoid adding yet another parameter to the parser method, but I do not think it can be avoided. The proper solution is to do lazy-loading of references, as I have mentioned before I think, where we do not resolve the reference until it is needed. This requires quite a lot of code though, so the first option is currently the easiest.
- Arjen
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103464/#review9076
-----------------------------------------------------------
On Dec. 18, 2011, 10:30 p.m., Felix Rohrbach wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103464/
> -----------------------------------------------------------
>
> (Updated Dec. 18, 2011, 10:30 p.m.)
>
>
> Review request for Gluon and Arjen Hiemstra.
>
>
> Description
> -------
>
> This patch assumes that all objects in d->objects don't have any parents yet. If this is wrong, the patch is wrong. I don't quite understand all that parser stuff, so I didn't check this myself.
>
>
> Diffs
> -----
>
> core/gdl/objecttreebuilder.cpp 4dcefa8
>
> Diff: http://git.reviewboard.kde.org/r/103464/diff/diff
>
>
> Testing
> -------
>
> - My problem is solved
> - Invaders still loads into creator and can be played.
>
>
> Thanks,
>
> Felix Rohrbach
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/gluon/attachments/20111219/d8d8493a/attachment.html>
More information about the Gluon
mailing list