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

merged 1 commit into from
Dec 5, 2016

Conversation

dmelikhov
Copy link
Contributor

DebugRecursively attribute needs to be processed after all children are added.


/** 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

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

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.

@czyzby czyzby added the bug label Dec 5, 2016
@czyzby czyzby added this to the 1.9 milestone Dec 5, 2016
@czyzby czyzby merged commit ba8ac44 into czyzby:master Dec 5, 2016
@czyzby
Copy link
Owner

czyzby commented Dec 5, 2016

Your implementation was OK (and it seems that I used some similar "tricks" to set up similar properties), but I usually went with anonymous classes for readability. (Although they are far harder to read than Java 8 lambdas, but hey - we all love backwards compatibility.) Even if they have some slight overhead on mobile platforms, in case of debug rendering attribute I don't think we should worry too much about an extra class+object being defined.

I refactored the code slightly to match other similar attributes. Still, thanks for finding the bug and actually fixing it instead of just creating an issue. ; )

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants