views:

67

answers:

1

I've got an interface inheritance issue that has been vexing me for some time. It doesn't seem to make any sense, and I can only conclude that I'm missing something fundamental.

Overview

The code below is from part of a fluent interface for our ORM tool. It provides a SQL-like syntax for pulling data from the database. You don't have to completely grok all the interrelations to understand the problem -- the real issue is the EndClause method.

The EndClause Issue

There's a method called EndClause that doesn't show up in one expected spot -- IOrderQueryRoot. As far as I know, it should show up because it inherits from two different interfaces that both have a method called EndClause, but when I consume an object that implements IOrderQueryRoot, EndClause does not pop up in intellisense.

There are some more implementation details below.

First though, if you look at IOrderQueryRoot (which contains EndClause), you can see that it inherits IHasOrderLogicalOperators, and also IHasOrderFields (which also contains EndClause).

Public Interface IHasOrderLogicalOperators
    Function [And]() As IHasOrderFields
    Function [AndNot]() As IHasOrderFields
    Function [Not]() As IHasOrderFields
    Function [Or]() As IHasOrderFields
    Function [OrNot]() As IHasOrderFields

    Function EndClause() As IHasOrderLogicalOperators
End Interface

Public Interface IHasOrderFields
    Function OrderID(ByVal value As Int32) as IHasOrderLogicalOperators
    Function OrderID() As IHasOrderComparisonOperators
    Function PracticeID(ByVal value As Int32) as IHasOrderLogicalOperators
    Function PracticeID() As IHasOrderComparisonOperators
    'note: I cut about a page of additional order-related fields you don't need to see.

    Function BeginClause() As IHasOrderFields
    Function EndClause() As IHasOrderLogicalOperators
End Interface

Public Interface IOrderQueryRoot
    Inherits IHasOrderFields, IHasOrderLogicalOperators

End Interface

I think the problem must have something to do with the fact that the EndClause method comes into IOrderQueryRoot twice from different places in the inheritance chain. It does need to work that way.

Since you might want to see the place where I actually consume the interfaces, here's the code I'm using:

    Public Function EndClause() As IHasOrderLogicalOperators Implements IHasOrderFields.EndClause, IHasOrderLogicalOperators.EndClause
        Me.Query.EndClause()

        Return New OrderQueryElement(Query)
    End Function

At this point, the interface is working fine -- if I were to remove this method, VS would scream that I have to implement both EndClause methods. The problem is one level down, when the "end developer" is trying to actually write code against the interface.

Please let me know if something jumps out at you -- this one has been driving me crazy for a long time!

+2  A: 

The reason why this doesn't exist in Intellisense is that calling the function EndClause via the interface IOrderQueryRoot is illegal and results in a compiler error. The reason why is it's not possible to distinguish from the following code if you should call IHasOrderLogicalOperators.EndClause or IHasOrderFields.EndClause.

Dim v1 As IOrderQueryRoot
v1.EndClause()

Intellisense strives to only suggest legal code. This code is not legal and hence it is not listed.

Yes, in your implementation of IOrderQueryRoot the resolution is unambiguous as there is a single function. For the raw IOrderQueryRoot though this resolution is ambiguous and hence correctly not listed.

JaredPar
Just one thought -- I get that there's an ambiguity problem, but if this is a problem, shouldn't VS be yelling at me?
Brian MacKay
I guess the answer is that VS is pretty good but doesn't catch absolutely every weird scenario, eh?
Brian MacKay
@brian: Does it compile?
Sky Sanders
That's the thing -- it does compile. But I think Jared is right. It's an ambiguity problem and I need to do some clever refactoring. Hope it's actually possible.
Brian MacKay
Yeah, I tried hiding one and no good. But it does compile. I think with a more coherent design you will both solve your design time problem and end up with a stronger api.
Sky Sanders
@Sky Sanders: Well, it's a fluent API... Needs to be able to handle things like: Order.Select.OrderID.Between(5, 10).AndNot.OrderStatus(5).OrderBy(OrderCreationDate, Descending) ... It's actually been working for years aside from this one little problem, but if you know a less complicated way to do this, please let me know :)
Brian MacKay
Anyway, thanks for your help, both of you.
Brian MacKay
personally, if it works and is in production, i wouldn't make any functional changes. thats why i concluded with refactor or suck it up. lol.
Sky Sanders
@Brian, there is nothing wrong with the way you defined the implementation of the EndClause method. It's 100% legal code. It's the calling of the method which is ambiguous. It's an ambiguity which can be solved though so no warning is issued at the point of definition.
JaredPar