Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add dynamic callbacks mechanism as alternative for StructSink #89

Merged
merged 14 commits into from
Sep 16, 2016

Conversation

jvdb
Copy link
Contributor

@jvdb jvdb commented Sep 14, 2016

Resolves #12.

@codecov-io
Copy link

codecov-io commented Sep 14, 2016

Current coverage is 99.14% (diff: 100%)

Merging #89 into master will increase coverage by 0.03%

@@             master        #89   diff @@
==========================================
  Files            78         81     +3   
  Lines          1003       1049    +46   
  Methods           0          0          
  Messages          0          0          
  Branches        181        186     +5   
==========================================
+ Hits            994       1040    +46   
  Misses            1          1          
  Partials          8          8          

Powered by Codecov. Last update 16b1bc9...a0c8655

@rdvdijk
Copy link
Contributor

rdvdijk commented Sep 15, 2016

Coverage went down, I think we can remove some dead code from the TraceCallbackList, add an explicit test for the BaseCallback and the new Environment constructors.

}

@Override
public String toString() {
return "stream: " + input + "; offset: " + offset + "; order: " + order;
return "stream: " + input + "; offset: " + offset + "; order: " + order + "; callbacks: " + callbacks;
Copy link
Contributor

Choose a reason for hiding this comment

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

(Apparently there is a new way of reviewing on GitHub, let's see!)

We need a test for toString() with actual callbacks. The current toString() tests Environments without callbacks.

handleCallbacks(environment.callbacks, token);
}

private void handleCallbacks(final TokenCallbackList callbacks, final Token token) {
Copy link
Contributor

@rdvdijk rdvdijk Sep 15, 2016

Choose a reason for hiding this comment

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

I don't think we have explicit tests yet for this code, add some.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Excellent point! I had a hard time coming up with a good test however, which indicated that it probably shouldn't be a public API. To fix this I moved the method to the Token base class, which greatly simplified the implementation.

import io.parsingdata.metal.data.ParseResult;
import io.parsingdata.metal.token.Token;

public class BaseCallback implements Callback {
Copy link
Contributor

Choose a reason for hiding this comment

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

Add some tests for this class.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is tested, but because it is not abstract, coverage requires a test that doesn't inherit from BaseCallback in order to execute the handleSuccess() and handleFailure() methods. I've reverted it to an abstract class.

Clients can trivially recreate the adapter pattern if they need it. Providing an abstract class seems cleaner for Metal I think.


public interface Callback {

void handle(final Token token, final ParseResult result);
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's get into the habit of adding Javadoc to new code...

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've added #9 to the 5.0.0 milestone. It's better to document the important stuff first I think.

return new TokenCallbackList(checkNotNull(head, "head"), this);
}

public TokenCallbackList add(final TokenCallbackList list) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this method is dead code, remove it.

@@ -105,7 +105,7 @@ public void encoding() {
@Test
public void data() {
final Environment environment = stream(1, 2);
final String envString = "stream: InMemoryByteStream(2); offset: 0; order: graph(EMPTY)";
final String envString = "stream: InMemoryByteStream(2); offset: 0; order: graph(EMPTY); callbacks: ";
Copy link
Contributor

Choose a reason for hiding this comment

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

(See my earlier "we need a test for toString()" 😉)

@@ -25,7 +26,7 @@

@Test
public void getValueOnEmpty() {
assertNull(ByName.getValue(ParseGraph.EMPTY, "name"));
TestCase.assertNull(ByName.getValue(ParseGraph.EMPTY, "name"));
Copy link
Contributor

Choose a reason for hiding this comment

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

Not sure what happened here, but use a static import as before. Also: I think we shouldn't use TestCase.* but Assert.*.

@jvdb jvdb merged commit 505f1fc into master Sep 16, 2016
@jvdb jvdb deleted the dynamic-callbacks branch September 16, 2016 14:32
@jvdb jvdb mentioned this pull request Oct 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants