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

Fixture interaction received method as a String rather than "method" object directly #911

Merged
merged 7 commits into from Jun 16, 2016

Conversation

Projects
None yet
3 participants
@LudovicVa
Contributor

LudovicVa commented May 6, 2016

While developing a Fixture interaction, I don't understand why the "Fixture Interaction" interface is not able to find the actual methods itself, rather than being given as an argument.
It is not symetrical with the way it can create new instances (as classname is given as a string, rather than a "class" object directly).

In my particular case, it will make my Fixture interaction more elegant (as I need the ability to basically "rename" methods. For now, I use a FixtureProxy which wraps a decision table into a dynamic decision table).

I also added a "cached interaction" class which I believe, can improve performance in some cases (as reflexion is not the fatest thing in Java). It simply caches method, class, and constructors.

@LudovicVa

This comment has been minimized.

Show comment
Hide comment
@LudovicVa

LudovicVa May 6, 2016

Contributor

I just realized it makes the "InteractionAwareFixture" a bit odd. I'm not sure where we should put it.
I wonder if it really needs to take "FixtureInteraction" as an argument. IMO, "InteractionAwareFixture" is sort of a lightweight "FixtureInteraction", thus it doesn't need to call FixtureInteraction to invoke the method.
Or we can keep the old interface of "methodInvoke" in the "FixtureInteraction" interface and explain that it is required only for "InteractionAwareFixture" compatibility ??

Contributor

LudovicVa commented May 6, 2016

I just realized it makes the "InteractionAwareFixture" a bit odd. I'm not sure where we should put it.
I wonder if it really needs to take "FixtureInteraction" as an argument. IMO, "InteractionAwareFixture" is sort of a lightweight "FixtureInteraction", thus it doesn't need to call FixtureInteraction to invoke the method.
Or we can keep the old interface of "methodInvoke" in the "FixtureInteraction" interface and explain that it is required only for "InteractionAwareFixture" compatibility ??

@@ -53,7 +53,7 @@ public void create(String instanceName, String className, Object[] args)
public void addPath(String path) {
if (!paths.contains(path)) {
paths.add(path);
paths.add(0, path);

This comment has been minimized.

@amolenaar

amolenaar May 31, 2016

Collaborator

Why prepend instead of append?

@amolenaar

amolenaar May 31, 2016

Collaborator

Why prepend instead of append?

This comment has been minimized.

@LudovicVa

LudovicVa Jun 2, 2016

Contributor

Previously, we append the path at the end of the list. However, each time we looked through the paths imported to find a class, the list was reversed. I removed the piece of code with was a little CPU consuming for nothing if we simply add at the head of the list.

@LudovicVa

LudovicVa Jun 2, 2016

Contributor

Previously, we append the path at the end of the list. However, each time we looked through the paths imported to find a class, the list was reversed. I removed the piece of code with was a little CPU consuming for nothing if we simply add at the head of the list.

@amolenaar

This comment has been minimized.

Show comment
Hide comment
@amolenaar

amolenaar May 31, 2016

Collaborator

It seems okay to move the method resolution out of the "fixed" executor logic into the Interaction, so we can change the way methods are invoked.

I saw a few things on which I made a remark. Nothing special. I think it would be good to keep the old interface around for a while (with a @Deprecated annotation), so old code will not break instantly. We do not have a common base class, do we?

I miss some tests for the CachedInteraction class.

@fhoeben Can you have a look at this?

Collaborator

amolenaar commented May 31, 2016

It seems okay to move the method resolution out of the "fixed" executor logic into the Interaction, so we can change the way methods are invoked.

I saw a few things on which I made a remark. Nothing special. I think it would be good to keep the old interface around for a while (with a @Deprecated annotation), so old code will not break instantly. We do not have a common base class, do we?

I miss some tests for the CachedInteraction class.

@fhoeben Can you have a look at this?

@LudovicVa

This comment has been minimized.

Show comment
Hide comment
@LudovicVa

LudovicVa Jun 2, 2016

Contributor

I agree that it would be a shame to directly remove the old interface. I don't know how you want to manage having both at the same time. Maybe we can have the old one "wrapped" into the new one, if declared in the config file or via a plugin ?

Contributor

LudovicVa commented Jun 2, 2016

I agree that it would be a shame to directly remove the old interface. I don't know how you want to manage having both at the same time. Maybe we can have the old one "wrapped" into the new one, if declared in the config file or via a plugin ?

}
private static class MethodKey {

This comment has been minimized.

@fhoeben

fhoeben Jun 5, 2016

Contributor

make all fields final?

@fhoeben

fhoeben Jun 5, 2016

Contributor

make all fields final?

This comment has been minimized.

@LudovicVa

LudovicVa Jun 6, 2016

Contributor

Yes, indeed, there have to stay constant

@LudovicVa

LudovicVa Jun 6, 2016

Contributor

Yes, indeed, there have to stay constant

import java.util.HashMap;
import java.util.Map;
public class CachedInteraction extends DefaultInteraction {

This comment has been minimized.

@fhoeben

fhoeben Jun 5, 2016

Contributor

I believe all (static) fields could be made final, correct?

@fhoeben

fhoeben Jun 5, 2016

Contributor

I believe all (static) fields could be made final, correct?

This comment has been minimized.

@LudovicVa

LudovicVa Jun 6, 2016

Contributor

Yes, we can

@LudovicVa

LudovicVa Jun 6, 2016

Contributor

Yes, we can

return MethodExecutionResult.noMethod(methodName, instance.getClass(), args.length);
}
protected Method findMatchingMethod(String methodName, Class<?> k, int nArgs) {

This comment has been minimized.

@fhoeben

fhoeben Jun 5, 2016

Contributor

Since the signature is being changed, why not supply all args (or at least their types) to this method?
If an implementation chooses to use only the number of arguments: fine, but that would allow implementing subclasses the option to actually look more closely.

@fhoeben

fhoeben Jun 5, 2016

Contributor

Since the signature is being changed, why not supply all args (or at least their types) to this method?
If an implementation chooses to use only the number of arguments: fine, but that would allow implementing subclasses the option to actually look more closely.

This comment has been minimized.

@LudovicVa

LudovicVa Jun 6, 2016

Contributor

Indeed, that makes sense. However, findMatchingMethod (if you speak about this method) is not part of the interface, so other implementation can look more closely to method arguments.

@LudovicVa

LudovicVa Jun 6, 2016

Contributor

Indeed, that makes sense. However, findMatchingMethod (if you speak about this method) is not part of the interface, so other implementation can look more closely to method arguments.

@fhoeben

This comment has been minimized.

Show comment
Hide comment
@fhoeben

fhoeben Jun 5, 2016

Contributor

Just a bit of nitpicking: why are not all if's followed by a single space?
I also saw some else clauses missing a space after }, or before, a {...

Contributor

fhoeben commented Jun 5, 2016

Just a bit of nitpicking: why are not all if's followed by a single space?
I also saw some else clauses missing a space after }, or before, a {...

@fhoeben

This comment has been minimized.

Show comment
Hide comment
@fhoeben

fhoeben Jun 6, 2016

Contributor

Some more remarks/questions?

  • The 'old interface' referred to above, is that InteractionAwareFixture? I hope that will not be deprecated I use this a lot to have my fixtures do aspect orient behavior specific to them (which I believe is different to the general concept of Slim interacting with all fixtures).
  • Should the CachedInteraction become the new 'default' interaction used by Slim? How much performance benefit does it offer, for instance on FitNesse's own tests?
Contributor

fhoeben commented Jun 6, 2016

Some more remarks/questions?

  • The 'old interface' referred to above, is that InteractionAwareFixture? I hope that will not be deprecated I use this a lot to have my fixtures do aspect orient behavior specific to them (which I believe is different to the general concept of Slim interacting with all fixtures).
  • Should the CachedInteraction become the new 'default' interaction used by Slim? How much performance benefit does it offer, for instance on FitNesse's own tests?
@LudovicVa

This comment has been minimized.

Show comment
Hide comment
@LudovicVa

LudovicVa Jun 6, 2016

Contributor

Regarding the formatting, it's because I'm a lazy coder ^^ And as I switch a lot between languages these days, it's hard to set up my mind to a particular coding style.

The old interface is (in my mind, maybe I misunderstood), the old FixtureInteraction. I don't believe it is desirable to remove the InteractionAwareFixture interface.

In Fitnesse own test, the performance diff is negligible. As it is an optimization, it don't think it is good to use it by default (at least for now), as it really depends on how your tests/fixture are written. In my particular case at work, I know (using measuring tool) that reflection is quite heavy. But I haven't found the time to measure the real benefits of caching.

Contributor

LudovicVa commented Jun 6, 2016

Regarding the formatting, it's because I'm a lazy coder ^^ And as I switch a lot between languages these days, it's hard to set up my mind to a particular coding style.

The old interface is (in my mind, maybe I misunderstood), the old FixtureInteraction. I don't believe it is desirable to remove the InteractionAwareFixture interface.

In Fitnesse own test, the performance diff is negligible. As it is an optimization, it don't think it is good to use it by default (at least for now), as it really depends on how your tests/fixture are written. In my particular case at work, I know (using measuring tool) that reflection is quite heavy. But I haven't found the time to measure the real benefits of caching.

@amolenaar amolenaar merged commit 22e1d9b into unclebob:master Jun 16, 2016

amolenaar added a commit that referenced this pull request Jun 16, 2016

Merge pull request #911 from LudovicVa/master
Fixture interaction received method as a String rather than "method" object directly

@amolenaar amolenaar added this to the Next Release milestone Jun 16, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment