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

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

Ok, I'm happy with that.  I'm sure the users will be too!

I've also been thinking about some sort of compatability layer to help
the transition.  I'm not sure how yet.  We tried it with jMock, but
(a) it wasn't really a compatability layer, and (b) it was a too much
work for the dev-team (i.e. me!).

--Nat.

On 5/24/05, Thibaut Barr=E8re <thi...@gm...> wrote:
> Hi Nat
>=20
> > 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?
>=20
> 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.
>=20
> IMHO we should only fix simple bugs on NMock 1, and concentrate on NMock =
2.
>=20
>=20
> Thibaut
>=20
>=20
> > What do people think?  How should we approach this?
> >
> > --Nat.
> >
> >
> > 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 onl=
y
> > > 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 chan=
ge
> > > the way we store the expectations / method registrations, which use
> > > the method name as a key in current code (see _methods Hashtable), an=
d
> > > use something (such as the signature) which takes the parameters type=
s
> > > 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 mana=
ged
> > > > 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
> > >
> >
>