Skip to content
This repository has been archived by the owner on May 27, 2021. It is now read-only.

Fixed DebugRecursively attribute. #47

Merged
merged 1 commit into from
Dec 5, 2016
Merged

Fixed DebugRecursively attribute. #47

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 17 additions & 1 deletion .../java/com/github/czyzby/lml/parser/impl/attribute/group/DebugRecursivelyLmlAttribute.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,21 +2,37 @@

import com.badlogic.gdx.scenes.scene2d.Group;
import com.github.czyzby.lml.parser.LmlParser;
import com.github.czyzby.lml.parser.action.ActorConsumer;
import com.github.czyzby.lml.parser.tag.LmlAttribute;
import com.github.czyzby.lml.parser.tag.LmlTag;
import com.github.czyzby.lml.util.LmlUtilities;

/** See {@link Group#setDebug(boolean, boolean)}. Second method argument is always true, so this method sets debug for
* all children; for non-recursive debug, use default debug attribute. Mapped to "debugRecursively".
*
* @author MJ */
public class DebugRecursivelyLmlAttribute implements LmlAttribute<Group> {
private static class DebugAction implements ActorConsumer<Object, Object> {
Copy link
Owner

@czyzby czyzby Dec 5, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't have to use <Object, Object> generics, I'm pretty sure you can just go ahead and use <Group, Void>, so you don't have to cast the actor to Group manually.

Copy link
Contributor Author

@dmelikhov dmelikhov Dec 5, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Second generic parameter is used as an argument in consume. So I could use <Void, Group>, but LmlUserObject#addOnCloseAction is requiring ActorConsumer<?, Object> so I have to use <Void, Object> but I think <Object, Object> looks more clear.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I might have mixed it up with Java 8 Function. Now that I think about it, the generics order could have been better.

LmlUserObject is pretty much internal API, and I may have chosen some questionable designs to escape Java's generics and reflection hell. I'll accept this PR as is (once I have some time to test it - I'm currently at work), and I'll see if this can be achieved without ActorConsumer altogether.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have tried to make it similar to OnClose attribute, as it is also processed after the actor's tag is closed.

private boolean value;

private DebugAction(boolean value) {
this.value = value;
}

@Override
public Object consume(Object actor) {
((Group) actor).setDebug(value, true);
return null;
}
}

@Override
public Class<Group> getHandledType() {
return Group.class;
}

@Override
public void process(final LmlParser parser, final LmlTag tag, final Group actor, final String rawAttributeData) {
actor.setDebug(parser.parseBoolean(rawAttributeData, actor), true);
LmlUtilities.getLmlUserObject(actor).addOnCloseAction(new DebugAction(parser.parseBoolean(rawAttributeData)));
}
}