I got enlightened while writing a reply... Assume I have a method f in some interface I:
void f(Vehicle V); After creating a mock for the interface, I want to describe the expectation of the f method. I impl = mock.StrictMock<I>(); I don't see any value in using Expect on f with a type argument of Vehicle, i.e. impl.Expect ( x => x. f ( Arg<Vehicle>.Is.TypeOf) ); The compiler will only accept a Vehicle to be passed to f, a Human or int or double will not do. But if I have Car as a subclass of Vehicle, the following could be interesting: impl.Expect ( x => x.f (Arg.Is.TypeOf<Car>) ); (The enlightenment came while writing the previous line) What I want is doable like this: impl.Expect (x => x.f (Arg<Car>.Is.TypeOf )); and works fine. So, please forget about my request. The current state is quite fine. Thank you all for trying to show it to me. Jean-Marie On Sep 15, 1:38 pm, Tim Barcz <[email protected]> wrote: > I don't know that I quite understand what you're trying to do but the > compiler will not check this for you. > > In fact you can say Arg<long>.Is.EqualTo("hello world") since under the > covers EqualTo takes in an object. > > Kind of a lengthy explanation but the ArgConstraints don't really do a lot > of type checking (for good reason). I just fixed a bug last week where > Arg<long>.Is.EqualTo(1) was not working because the 1 was being inferred as > an Int32. When the actual call was made the parameter comes in as an Int64 > and won't match inside ArgManager. > > Kind of confusing I know. > > > > > > On Tue, Sep 15, 2009 at 3:17 AM, Timores <[email protected]> wrote: > > > I may have misunderstood the formalism here. > > If a method is declared as taking a T, I don't understand the point of > > setting the constraint of checking that the argument is really a T. > > The compiler already does this, if I am not mistaken. > > I am interested in checking that the argument is actually of type U, > > where U derives from T. > > > Does this make sense ? > > > On Sep 14, 8:45 pm, bill richards <[email protected]> > > wrote: > > > Surely you want > > > > T TypeOf<T> > > > > and not > > > > U TypeOf<T> > > > > The first one says "when I say give me an object of type T I expect to > > > be given an object of type T." > > > The second one says "when I say give me an object of type T, I expect > > > to be given an objecct of type U" > > > > I know which one makes sense to me. > > > > Or have I missed something? > > > > On Sep 14, 12:41 pm, Timores <[email protected]> wrote: > > > > > Hi, > > > > In RhinoMocks 3.6 there is the TypeOf property in Arg<T>. It checks > > > > that the argument is really of type T. I am new to mocks, so I am a > > > > bit hesitant to ask if this is really useful. The compiler will not > > > > let us pass anything else than a T as the argument. > > > > > What I'd like instead is what I think is in the docs, i.e. a TypeOf<U> > > > > property, like this: > > > > > public T TypeOf<U> > > > > : where U : T > > > > { > > > > get > > > > { > > > ArgManager.AddInArgument(Is.TypeOf<U>()); > > > > return default(T); > > > > } > > > > } > > > > > When a method accepts an abstract class as a parameter, it is useful > > > > in a unit test to check that an argument is of a more derived type. > > > > > What do you think ? > > > > > Regards, > > > > Jean-Marie > > -- > Tim Barcz > Microsoft ASPInsiderhttp://timbarcz.devlicio.ushttp://www.twitter.com/timbarcz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rhinomocks?hl=en -~----------~----~----~----~------~----~------~--~---
