Stop passing IFakeObjectCallRule to OnAfterCallIntercepted in 5.0.0

[thomaslevesque]

In #1491 (comment), @blairconrad said:

As I hint at, this hack wouldn't be necessary if IFakeObjectCallRule didn't expose Apply. But it needs to in order for people to create their own rules.

But I don't think that IInterceptionListener.OnAfterCallIntercepted needs to be passed an object that has an Apply method; there's no need for OnAfterCallIntercepted to call Apply.
I don't even know why it would need to call IsApplicable or NumberOfTimesToCall. Shall we explore changing this in a future major version? We could supply OnAfterCallIntercepted with a different interface that's a restricted version of IFakeObjectCallRule, or even remove the IFakeObjectCallRule parameter.

@thomaslevesque replied:

Seems like a good idea. I don't see any value in having the call rule available in OnAfterCallIntercepted, except for information purposes. Maybe we could just pass a string describing the rule, or just the type of the rule.

[blairconrad]

@thomaslevesque, I think passing the type is a good idea.

[thomaslevesque]

@thomaslevesque, I think passing the type is a good idea.

Thinking about this again, I wonder if it's the right thing to do. The type isn't always enough to identify a rule. For instance, the user could create a custom rule, and add several different instances of that rule. Maybe we could pass some kind of "rule descriptor" rather than just the type? Or this:

We could supply OnAfterCallIntercepted with a different interface that's a restricted version of IFakeObjectCallRule

Of course, it's more work for little benefit, since nobody seems to use custom rules...

[blairconrad]

The type isn't always enough to identify a rule. For instance, the user could create a custom rule, and add several different instances of that rule.

It's true. Of course, if it's all their code, they should be able to figure out which one it was. On the other hand, if it's one of our rules, what's the benefit of them finding out which one it was?

Really, I'm not sure why anyone wants to know which rule matched.

We could supply OnAfterCallIntercepted with a different interface that's a restricted version of IFakeObjectCallRule

Sure, that would be fine.

Of course, it's more work for little benefit, since nobody seems to use custom rules...

… and probably even fewer the interceptors. But if you'd like to (or have me) make a new interface for this purpose, I do not mind.

[thomaslevesque]

Bah, forget it, it's not worth the trouble.

[blairconrad]

So you want to stick with type? We could remove the rule-ish parameter altogether.

[thomaslevesque]

I was just wondering about that. The type isn't enough information, but we don't want to go out of our way to provide more. So yes, maybe we should just remove the parameter.

[thomaslevesque]

I'll send a PR with both options.

[thomaslevesque]

This change has been released in FakeItEasy 5.0.0.