Re: [Nmock-general] NMO-37 - Indexers in c# are not working properly

[<thi...@gm...>]

Hi Nat

> However, is it worth fundamentally changing the semantics of NMock
> expectations?  I'm going to check NMock-2 into CVS this thursday,
> which dispatches on argument values and more.  The API and semantics
> are different, but I've put the new code into a different namespace to
> allow a gradual transition from NMock to NMock2.  However, if the
> semantics of NMock are going to change, how are users going to upgrade
> -- they can't gradually upgrade to the latest version of NMock1 -- and
> is this going to confuse users?

Although I'm suffering myself from that ;), I think we should avoid
putting too much effort on nmock1... I'm aware that the change
required to fix NMO-37 and other related issues will necessarily bring
regressions into existing test code for some users, and involves
somehow a big change in the semantics of NMock 1.

IMHO we should only fix simple bugs on NMock 1, and concentrate on NMock 2.


Thibaut


> What do people think?  How should we approach this?
>=20
> --Nat.
>=20
>=20
> On 5/24/05, Thibaut Barr=E8re <thi...@gm...> wrote:
> > Hi Johan
> >
> > have a look at my previous post named SetupResult behavior and NMO-37
> > (indexed properties). Here's the current state of my "investigation"
> > (I'm discovering the source so please bear with me ;)
> >
> > 1/ About c# indexed properties, with SetupResult and ExpectAndReturn
> >
> > Actually SetupResult works for index property if there is only one
> > index definition, eg the following does work :
> >
> > public interface IFoo
> > {
> >         string this[int index] { get; }
> > }
> >
> > [Test]
> > public void UniqueIndexedProperty()
> > {
> >         DynamicMock mock =3D new DynamicMock(typeof(IFoo));
> >         mock.SetupResult("Item","TheValue",typeof(int));
> >         IFoo foo =3D (IFoo)mock.MockInstance;
> >         Assert.AreEqual("TheValue",foo[45]);
> > }
> >
> > The failure appears when you have more than one index, eg:
> >
> > public interface IFoo
> > {
> >         string this[int index] { get; }
> >         string this[string index] { get; }
> > }
> >
> > as this leads to ambiguous match and other issues the way it's
> > currently implemented. So actually indexed properties do work for
> > SetupResult as long as there is no more than one index... The same
> > applies for ExpectAndReturn.
> >
> > 2/ about non c# indexed properties
> >
> > Did you actually already try to use non c# index properties (with only
> > one index) ? I didn't test that, but I suppose it could already work
> > as long as you only have one index defined (else we go back to issue
> > described in 1/).
> >
> > 3/ about helping
> >
> > sure you can. What I'd like to get first is a test fixture to isolate
> > each of the cases we want to implement (more or less what I wrote
> > above, but for each case : one indexed property with setupresult, one
> > with expectandreturn, two with setupresult, two with expectandreturn).
> >
> >
> >
> >
> >
> > =3D> to other nmock devs: in order to fix this, we would have to change
> > the way we store the expectations / method registrations, which use
> > the method name as a key in current code (see _methods Hashtable), and
> > use something (such as the signature) which takes the parameters types
> > into account in the key. Any opinion before I try to proceed ?
> >
> >
> >
> > kind regards
> >
> > Thibaut
> >
> >
> > 2005/5/24, Johan Appelgren <joh...@gm...>:
> > > On 5/16/05, Thibaut Barr=E8re <thi...@gm...> wrote:
> > > > If nothing has already been done for this one, I can look at it
> > > > (unless there are more critical issues)
> > > >
> > > > Thibaut
> > >
> > > Have you had time to make any progress on this?
> > >
> > > If support for the only indexed property that C# can generate is
> > > added, would it be possible to also extend it to support indexed
> > > properties generally. Like for those that can be defined using manage=
d
> > > c++? The reason for this is that I want to mock some com interop
> > > interfaces that use indexed properties extensively.
> > >
> > > If I can help in some way let me know.
> > >
> > > /Johan
> > >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > Want to be the first software developer in space?
> > Enter now for the Oracle Space Sweepstakes!
> > http://ads.osdn.com/?ad_idt12&alloc_id=16344&opclick
> > _______________________________________________
> > Nmock-general mailing list
> > Nmo...@li...
> > https://lists.sourceforge.net/lists/listinfo/nmock-general
> >
>