Re: [MO-java-dev] dynamic mock cannot handle overloaded methods

[Nat P. <nat...@b1...>]

On Tue, 2002-11-19 at 15:16, Barry Kaplan wrote:
> Nat Pryce wrote:
> 
> >I designed the API that way for simplicity rather than completeness.  In
> >all my use of the dynamic mock library I have not found a need for
> >overloaded methods. Overloaded methods they do not seem to be used in
> >interfaces.  The interfaces which are most likely to use overloaded
> >methods (DataOutput for example) don't use them to, I guess, avoid
> >silent type coercions and all the tricky bugs they cause.
> >
> >Supporting overloaded methods would make the API really awkward unless
> >the Mock class completely hid the lookup of methods behind a convenient
> >set of functions.
> >
> I believe I can do it without any change to the public interface. 
> Roughly, what I was thinking of was to add a method to MockCall to 
> return Class[] corresonding to the method arguments. MockCall would 
> delegate to its [top-level] Constraints to get the Class's. Thus, given 
> the name and Class[], MockCall can get the Method and use that as the 
> key. (MockCall already looks up the Method when invoking a non-proxied 
> method, but in that case it already has the Object[]'s.) The one 
> limitation (until jdk 1.5) is that composite Constraint's will simply 
> give back the first Class of the first contained Constraint.

I'm confused about this:  

* MockCall *is* part of the public interface.

* Constraints do not specify the expected argument types, so I don't see
how querying for a list of constraints will help you overload on
argument types.

* MockCall objects do not have to have Constraints -- they can check
argument values in any way they choose.  For example, I have tests that
uses anonymous inner classes that implement MockCall and call JUnit
assertions in the call method.

* The MockCall method is very simple so that it is easy to create
anonymous inner classes that implement from MockCall.  I don't want to
add any additional methods to the MockCall interface to keep this
simplicity.

* Why do you want to add a method to query the state of a MockCall? 
What does the caller of this method do with the queried information? 
And why can the MockCall not do this?  (Law of Demeter/Tell Don't Ask).

I would like to see what the API would be like and how it would be used
before making such drastc changes.  From that we can work towards the
design of the internals.

> One of the other benefits of this approach is that invocations to 
> setupCall/expectCall can check that the MockCall represents an actual 
> method on the interface at the time the call is setup. As it is now, the 
> test can specify a set of arguments for a non-existant method. This type 
> of error won't manifest itself until Mock.invoke().

This is partly checked at the moment -- at least there is a check that a
method of that name exists.

> >Can you give us an example of where you need them?
> >  
> >
> The class I have been using to learn mocksobjects:
> 
> public interface Position {
>     int getQuantity(PositionBucketType bucketType, PositionTimeType 
> timeType);
>     int getQuantity(LongShort longShort, CreditType creditType, 
> PositionTimeType timeType);
>     ....
> }
> 
> Different components of our system know different aspects of a position. 
> The two methods above allow each to access the quantities 
> polymorphically without any ifs or switches.

Java does not dispatch methods polymorphically based on runtime argument
types.  If your code is calling overloaded methods you don't need ifs
and switches.

However, that's by-the-by.  The dynamic Mocks should support overloaded
methods.  I would just like to ensure that support of overloaded methods
does not make the common cases (no overloaded methods) harder to use.

Cheers,
	Nat.
-- 
Nat Pryce <nat...@b1...>
B13media