Naming Suggestion

[Nietz]

Hi all,

I am refactoring the amop for version 0.4, which i added a Policy for
named "All" for
following usage:

//------------------------------------------------------------------
TEST(MockObjectMethodMultipleAll)
{
TMockObject<IInterface> mock;

mock.Single(&IInterface::SimpleFunctionWithParams)
.Expects(All(1.0f, "Hello 1", "SomeText1"))
.Expects(All(2.0f, "Hello 2", "SomeText2"))
.Expects(All(3.0f, "Hello 3", "SomeText3"));

((IInterface*)mock)->SimpleFunctionWithParams(1.0f, "Hello 1",
"SomeText1");
((IInterface*)mock)->SimpleFunctionWithParams(2.0f, "Hello 2",
"SomeText2");
((IInterface*)mock)->SimpleFunctionWithParams(3.0f, "Hello 3",
"SomeText3");
}

But i think All is not a good name, and it used the same name for the
new function of
TMockObject (which is TMockObject::All, used for "default"
expectation. )

anyone could help me for a better name???

[Jarl Friis]

Nietz <rdesc...@gmail.com> writes:

What about "Parameters" or "Args"

Regarding the "Single" and "All". This could also be suffixed with
"Call" or (IMHO) even better: "SingleCall" and "EveryCall"

Jarl

[Nietzsche Cheng]

> What about "Parameters" or "Args"

I think it is better than "All", but these 2 names are still not good enough..

The full name of this policy will be something like "AllArgs or AllParamters",
but i think it is too long...

> Regarding the "Single" and "All". This could also be suffixed with
> "Call" or (IMHO) even better: "SingleCall" and "EveryCall"

This 2 are better too.. but IMHO i don't like the method name too long,
but do you think these 2 name too long?? i dont know.. these 2 methods will be
used on EVERY mock object's method, so it should be very short one, right?

[Jarl Friis]

"Nietzsche Cheng" <rdesc...@gmail.com> writes:

>> What about "Parameters" or "Args"
>
> I think it is better than "All", but these 2 names are still not good enough..
>
> The full name of this policy will be something like "AllArgs or
> AllParamters", but i think it is too long...

I agree here. Sine this "Policy" main purpose is to bring syntactic
sugar to the API, the name should be very short. To be honest you
could actually consider somthing like "_" it can't be shorter, and due
to koenig lookup, this wont polute as much as one would believe,
because it is placed in a namespace. Just like bind has special types
called "_1", "_2", etc. It's just an idea...

But why have a name at all, From an API users point of view I would
prefer nothing like

mock.Call(&IInterface::SimpleFunctionWithParams)
.Expects(1.0f, "Hello 1", "SomeText1")
.Expects(2.0f, "Hello 2", "SomeText2")
.Expects(3.0f, "Hello 3", "SomeText3");

> This 2 are better too.. but IMHO i don't like the method name too
> long, but do you think these 2 name too long?? i dont know.. these 2
> methods will be used on EVERY mock object's method, so it should be
> very short one, right?

Here I think readability, and clarity has much higher priority than
name shortness (we don't want names in the tradition of the 70's
C-style and unix, such as strdup, memcmp, memcpy), but you could cut
one of them, say "Call" and "EveryCall", this is also closer to some
other APIs.

So we will have

mock.Call(&IInterface::SimpleFunctionWithParams)
.Expects(1.0f, "Hello 1", "SomeText1")
.Expects(2.0f, "Hello 2", "SomeText2")
.Expects(3.0f, "Hello 3", "SomeText3");

and

mock.EveryCall(&IInterface::SimpleFunctionWithParams)
.Expects(1.0f, "Hello 1", "SomeText1");

Are you also renaming "Will" to "Return"

Jarl

[Nietzsche Cheng]

> I agree here. Sine this "Policy" main purpose is to bring syntactic
> sugar to the API, the name should be very short. To be honest you
> could actually consider somthing like "_" it can't be shorter, and due
> to koenig lookup, this wont polute as much as one would believe,
> because it is placed in a namespace. Just like bind has special types
> called "_1", "_2", etc. It's just an idea...

I agree, "_" can't be shorter, but i reserved this "_" to the following usage:

class Interface
{
virtual void foo(int p1, int p2, int dontcare);
};

TMockObject<Interface> mock;

// We dont care about the last param.
mock.Single(All(1, 2, _))

>
> But why have a name at all, From an API users point of view I would
> prefer nothing like
>
> mock.Call(&IInterface::SimpleFunctionWithParams)
> .Expects(1.0f, "Hello 1", "SomeText1")
> .Expects(2.0f, "Hello 2", "SomeText2")
> .Expects(3.0f, "Hello 3", "SomeText3");

How about i just want to expect single parameter??
i preserved the old Expects<0>(1.0f) usage, but i have to separate
these 2 usage,
so do you have any idea ?? 2 different names?? Expects and ExpectOne<0>(1.0f) ??

> Here I think readability, and clarity has much higher priority than
> name shortness (we don't want names in the tradition of the 70's
> C-style and unix, such as strdup, memcmp, memcpy), but you could cut
> one of them, say "Call" and "EveryCall", this is also closer to some
> other APIs.
>
> So we will have
>
> mock.Call(&IInterface::SimpleFunctionWithParams)
> .Expects(1.0f, "Hello 1", "SomeText1")
> .Expects(2.0f, "Hello 2", "SomeText2")
> .Expects(3.0f, "Hello 3", "SomeText3");
>
> and
>
> mock.EveryCall(&IInterface::SimpleFunctionWithParams)
> .Expects(1.0f, "Hello 1", "SomeText1");
>

This one is perfect :) i will follow this.

> Are you also renaming "Will" to "Return"

Yes :)

[Jarl Friis]

"Nietzsche Cheng" <rdesc...@gmail.com> writes:

>> I agree here. Sine this "Policy" main purpose is to bring syntactic
>> sugar to the API, the name should be very short. To be honest you
>> could actually consider somthing like "_" it can't be shorter, and due
>> to koenig lookup, this wont polute as much as one would believe,
>> because it is placed in a namespace. Just like bind has special types
>> called "_1", "_2", etc. It's just an idea...
>
> I agree, "_" can't be shorter, but i reserved this "_" to the
> following usage:
>
> class Interface
> {
> virtual void foo(int p1, int p2, int dontcare);
> };
>
> TMockObject<Interface> mock;
>
> // We dont care about the last param.
> mock.Single(All(1, 2, _))
>
>>
>> But why have a name at all, From an API users point of view I would
>> prefer nothing like
>>
>> mock.Call(&IInterface::SimpleFunctionWithParams)
>> .Expects(1.0f, "Hello 1", "SomeText1")
>> .Expects(2.0f, "Hello 2", "SomeText2")
>> .Expects(3.0f, "Hello 3", "SomeText3");
>
> How about i just want to expect single parameter??

I didn't think of that...

However, All the calls always have all the arguments... So when you
say "expect a single parameter", you probably mean expect all
parameters, but only *validate* a single parameter.

I that case I will suggest (if technically possible) the following

mock.Call(&IInterface::SimpleFunctionWithParams)
.Expects(1.0f, "Hello 1", "SomeText1")//validates all args.
.Expects(2.0f, Ignore, Ignore)//validates only first arg.
.Expects(3.0f);//FAIL to compile due to argument NUMBER MISMATCH
.Expects(4.0f, 1.0f, 2.0f );//FAIL to compile due to argument TYPE MISMATCH

It would be a great usability improvement if this is possible. But I
think it will require type lists as described by Alexandrescu in
"Modern C++ Design", and the TReturnMatchBuilder should have an
additional template parameter, which is the typelist. But if such an
API is achieved, then there is no longer any need for the current way
of specifying expects.

> i preserved the old Expects<0>(1.0f) usage, but i have to separate
> these 2 usage,
> so do you have any idea ?? 2 different names?? Expects and
> ExpectOne<0>(1.0f) ??

If you want to keep the current usage (I discourage you to do that on
long term, but could be practical to keep on short term), I will
suggest you use two different names like you suggest: Expects and
ExpectOne<0>(1.0f)

Let me know if you run into any technical challenges in achieving the
above syntax for the API.

Jarl

[Nietzsche Cheng]

On Mon, Jun 23, 2008 at 7:01 PM, Jarl Friis <ja...@gavia.dk> wrote:
> I that case I will suggest (if technically possible) the following
>
> mock.Call(&IInterface::SimpleFunctionWithParams)
> .Expects(1.0f, "Hello 1", "SomeText1")//validates all args.
> .Expects(2.0f, Ignore, Ignore)//validates only first arg.
> .Expects(3.0f);//FAIL to compile due to argument NUMBER MISMATCH
> .Expects(4.0f, 1.0f, 2.0f );//FAIL to compile due to argument TYPE MISMATCH
>

your "Ignore" is equal to my "_" :)
So that is very easy to change my current approach to yours.

>> i preserved the old Expects<0>(1.0f) usage, but i have to separate
>> these 2 usage,
>> so do you have any idea ?? 2 different names?? Expects and
>> ExpectOne<0>(1.0f) ??
>
> If you want to keep the current usage (I discourage you to do that on
> long term, but could be practical to keep on short term), I will
> suggest you use two different names like you suggest: Expects and
> ExpectOne<0>(1.0f)
>

I agree with you. so i will not keep the old method. Just use the new
Expects for all situation.

[Jarl Friis]

"Nietzsche Cheng" <rdesc...@gmail.com> writes:

> On Mon, Jun 23, 2008 at 7:01 PM, Jarl Friis <ja...@gavia.dk> wrote:
>> I that case I will suggest (if technically possible) the following
>>
>> mock.Call(&IInterface::SimpleFunctionWithParams)
>> .Expects(1.0f, "Hello 1", "SomeText1")//validates all args.
>> .Expects(2.0f, Ignore, Ignore)//validates only first arg.
>> .Expects(3.0f);//FAIL to compile due to argument NUMBER MISMATCH
>> .Expects(4.0f, 1.0f, 2.0f );//FAIL to compile due to argument TYPE MISMATCH
>>
>
> your "Ignore" is equal to my "_" :)

You are right, I realise that now... Personally I prefer "Ignore" in
this case. Because it is short enough to be nice, and much more readable.

> So that is very easy to change my current approach to yours.

Cool. I am really impressed if you get the above API syntax to work...

Jarl

[Kirk Korver]

Nietz,

Are you changing the .Method to a .Call? Or is .Call what you have to use
with .Expect(s)?

I really like consistency. Changing the name from .Method to .Call is fine,
provided it is done everywhere. Know that I do not think it is required. As
for your first question. I like the name .ExpectedParams . The plural
implies that multiple parameters can be included, and the expected implies
well that we expect these values. Now if you can get .Expects to work and
still be consistent with the previous API I actually do prefer .Expects. I
throw out .ExpectedParams as an alternative.

When in doubt I think it is better to have more letters and be more clear.
We here all know what is going on, but others trying to learn the framework
need as many clues as is possible.

To that goal, if you have a _ that means Ignore, then please, PLEASE change
the API to accept Ignore also, or best only accept Ignore and drop support
for _ . You know that _ means ignore, but I think _ means a cat stepped on
the keyboard and erased the important words. :-)

Does this API change mean that all previous projects will not work?

=================

On a side note, I would really like if there were a method of a TMockObject
called .get() that would do exactly what the cast does; namely return a
pointer to the mocked object. Does anyone else agree, or is it just me that
would like to see this method exist?

=================

--Kirk

[Nietz]

On Jun 23, 11:35 pm, "Kirk Korver" <kirk_kor...@hotmail.com> wrote:
> Nietz,
>
> Are you changing the .Method to a .Call? Or is .Call what you have to use
> with .Expect(s)?

I am changing the .Method to 4 types of calls:

1. Call

This is used for checking the parameters and return value one time
for each expects and returns.
( The old Expects and Wills method )

mock.Call(&Interface::Foo).Expects(1.0f).Returns(100)
.Expects(2.0f).Returns(200);

CHECK_EQUAL(100, ((Interface*)mock)->Foo(1.0f) );
CHECK_EQUAL(200, ((Interface*)mock)->Foo(2.0f) );

CHECK_THROW(((Interface*)mock)->Foo(3.0f) );

2. EveryCall

This is used for checking the parameters and return value multiple-
times.
(The old expect and will method)

mock.EveryCall(&Interface::Foo).Expect(1.0f).Return(100);

CHECK_EQUAL(100, ((Interface*)mock)->Foo(1.0f) );
CHECK_EQUAL(100, ((Interface*)mock)->Foo(1.0f) );
CHECK_EQUAL(100, ((Interface*)mock)->Foo(1.0f) );
CHECK_EQUAL(100, ((Interface*)mock)->Foo(1.0f) );

3. Query

This is used for query the call counter only.

CHECK_EQUAL(4, mock.Query(&Interface::Foo).Count() );

4. Redirect

This is used for redirect the call to user defined function

mock.Redirect(&Interface::Foo).Do(&UserDefineFreeFuntion);

> Does this API change mean that all previous projects will not work?

Sorry.. you are right, but i think it is better to change make the api
change early as
the project glow up .. right ?

> When in doubt I think it is better to have more letters and be more clear.
> We here all know what is going on, but others trying to learn the framework
> need as many clues as is possible.
>
> To that goal, if you have a _ that means Ignore, then please, PLEASE change
> the API to accept Ignore also, or best only accept Ignore and drop support
> for _ . You know that _ means ignore, but I think _ means a cat stepped on
> the keyboard and erased the important words. :-)

Um.. yes, totally agree, i will use Ignore not the "_".

> On a side note, I would really like if there were a method of a TMockObject
> called .get() that would do exactly what the cast does; namely return a
> pointer to the mocked object. Does anyone else agree, or is it just me that
> would like to see this method exist?

Personally, i dont have need in my own projects, because the usage is
put the TMockObject
to some class :

ClassToTest obj(mock1, mock2);

CHECK(obj.FunctionToTest());

But i am thinking about providing a function of .Ref() to return a
reference of the Interface,
do you think it is needed ?

[Kirk Korver]

Nietz,

- Is it possible to combine the Call and the EveryCall?
- If you do provide the .ref() function then please provide a .get()
function as well. This begs a bigger question of, "Are these functions
necessary, or just nice to have?". What do other people think? My opinion is
that they are nice to have, and not required. I guess I do not care that
much about having a .get() in spite of what I just wrote.
- How do you feel about using the dereference operator T & operator *()
to return a reference to the mocked object? That way code that requires a
reference would look like this

// First one needs a pointer. Second one needs a reference
ClassToTest obj(mock1, *mock2);

CHECK(obj.FunctionToTest());

--Kirk

-----Original Message-----
From: amop-...@googlegroups.com [mailto:amop-...@googlegroups.com] On
Behalf Of Nietz
Sent: Monday, June 23, 2008 10:42 AM
To: amop group
Subject: [amop-group] Re: Naming Suggestion

I am changing the .Method to 4 types of calls:

1. Call
2. EveryCall
3. Query
4. Redirect

--------------------------------------------------------

[Timo Puronen]

Um.. yes, totally agree, i will use Ignore not the "_".

I liked _, probably because I've done little Scala lately in which _ means exactly the same you were planning (i.e. any value). Regarding the readability, I think that Expects(2.0f, _, _) is more readable as it emphasizes the relevant part (the given value which must match) and "hides" the irrelevant ones. Anyway, if everybody else prefers Ignore, let's use that.

About CMake, I can create initial CMakefiles for amop when I'll have some extra time, I'll try to do it during the weekend at latest.

Regards,
Timo

[Nietzsche Cheng]

> - Is it possible to combine the Call and the EveryCall?

Yes, infact, the original implement ( i mean version 0.3x ) is
combined the .Call and .EveryCall into .Method, but i do think the
usage of old Expects and Expect are quite
mis-leading. (I totally forget why i did that ..:P)

But using this new form ( thanks Jarl for the idea ), the misleading
is disappearing,
and we can use the single method "Expects" to check both cases , make
it more consistency.

"Are these functions necessary, or just nice to have?".

Good quest, I think they are nice to have only, so in my opinion now,
i prefer not to add these .ref and .get at this moment.

[Jarl Friis]

"Kirk Korver" <kirk_...@hotmail.com> writes:

> I really like consistency. Changing the name from .Method to .Call is fine,
> provided it is done everywhere. Know that I do not think it is required. As
> for your first question. I like the name .ExpectedParams . The plural
> implies that multiple parameters can be included, and the expected implies
> well that we expect these values. Now if you can get .Expects to work and
> still be consistent with the previous API I actually do prefer .Expects. I
> throw out .ExpectedParams as an alternative.

To be completely honest I will actually prefer "Expect" opposed to
"Expects", this is kind in line with the well known "Tell, don't ask"
principle. http://pragprog.com/articles/tell-dont-ask

In OO it is good practise give method names that states what YOU want
it to do. Not a name that states what the methods does for you.

> To that goal, if you have a _ that means Ignore, then please, PLEASE
> change the API to accept Ignore also, or best only accept Ignore and
> drop support for _ .

I vote for dropping "_" as well, In bind "_1" makes sense, since it is a
placeholder (of unknown meaning). But in this case. The meaning is
very concrete, and therefore should have a concrete name.

> Does this API change mean that all previous projects will not work?

I think that is what can be expected by a framework this early
(pre-1.0).

> On a side note, I would really like if there were a method of a TMockObject
> called .get() that would do exactly what the cast does; namely return a
> pointer to the mocked object. Does anyone else agree, or is it just me that
> would like to see this method exist?

I also think it is better with a method than a cast, but I would
prefere something else than get() (it is too generic), what about
"Pointer" or "ptr" or something like that. or at least
make the cast explicit.

And as Nietz also suggest I would really like a "Ref" method to return
a reference. It makes the code much easier to read when mocking
classes with operators, see
http://code.google.com/p/amop/wiki/GeneralDiscussion

So maybe "Ptr" and "Ref" is a good pair of methods.

Jarl

[Jarl Friis]

"Nietzsche Cheng" <rdesc...@gmail.com> writes:

>> - Is it possible to combine the Call and the EveryCall?
>
> Yes, infact, the original implement ( i mean version 0.3x ) is
> combined the .Call and .EveryCall into .Method, but i do think the
> usage of old Expects and Expect are quite
> mis-leading. (I totally forget why i did that ..:P)

Hi Kirk... You can also read the last few comments on
http://code.google.com/p/amop/wiki/GeneralDiscussion, starting from
May 30, 2008, that's actually where this discussion took place.

> "Are these functions necessary, or just nice to have?".
>
> Good quest, I think they are nice to have only, so in my opinion now,
> i prefer not to add these .ref and .get at this moment.

I deed, good question...

I too am now convinced that it would be better to delay the
introduction of these methods (if at all).

Kirk, your suggestion about operator*() to return a reference, may
actually be a very neat feature, it resembles the ideas from smart
pointers. And one can think of TMockObject's as VERY "smart" pointers,
so smart that it actually fakes the value behind the pointer :-). Very
nice idea... What does the rest of you think of this idea.

Jarl

[Nietz]

> About CMake, I can create initial CMakefiles for amop when I'll have some
> extra time, I'll try to do it during the weekend at latest.

Great, so seem to be we will have the CMake make file in 0.4 version.

[Jarl Friis]

Nietz <rdesc...@gmail.com> writes:

Not bad...

Jarl

[Kirk Korver]

Group,
Yes I also see these as smart pointers. Which is why I suggested the name
.get() to turn the actual pointer, to match the name of smart pointer
implementations.

After thinking about it, here is here is what I see as viable choices
Choice A) Provide cast (as is, not explicit) to return pointer, and * to
return the reference
Choice B) provide .ptr() to return pointer, and .ref() to return reference
Choice C) Do no change anything.

Of those two choices A is more convenient, less typing, choice B is more
typing, though more clear, and choice C is where we are today.

My vote would be for A.

My rational is that a "mocked object" IsA "object" and therefore should be
treated as one. If someone really wants the .ref() and .ptr() functions, all
they have to do is create a new class derived from TMockObject and add those
functions.

Comments?

[Nietz]

Kirk:

> Choice A) Provide cast (as is, not explicit) to return pointer, and * to
> return the reference
> Choice B) provide .ptr() to return pointer, and .ref() to return reference
> Choice C) Do no change anything.

It is tough choices.... although i will vote for C,
because the usage is much easier: (not because of i am lazy :P)

----------------------------------------------------------
testfunction(mock);

compare to:

testfunction((Interface*)mock);

----------------------------------------------------------

but i think there are a little bit asymmetric for the reference
version:

testfunction(*mock); // if we implemeted * operator.

I dont like B, if you guys think C plus * operator solution is not
good enough,
I can accept A.

[Kirk Korver]

Nietz,

Please add this to the file TestMockObject.cpp. There is no problem here, I
want it added to act as a prototype to show people how to deal with the case
where there are more than 1 method with a same name. The solution is
non-obvious.

TEST(Overloads1)
{
struct IOverloads
{
virtual int SimpleFunction() = 0;
virtual int SimpleFunction(int x) = 0;
};

// The method with no parameters
typedef int (IOverloads::*PMF0)();
PMF0 pmf0 = &IOverloads::SimpleFunction;

// The method with a single parameter
typedef int (IOverloads::*PMF1)(int);
PMF1 pmf1 = &IOverloads::SimpleFunction;

TMockObject<IOverloads> mock;

mock.Method(pmf0).Will(1);
mock.Method(pmf1).Will(2);

IOverloads * pI = mock;

CHECK_EQUAL(1, pI->SimpleFunction());
CHECK_EQUAL(2, pI->SimpleFunction(3));
};

--Kirk

[Kirk Korver]

Group,

Firstly I think there is a little confusion: choice C plus adding the *
operator is exactly the same as A. I wanted to emphasise that I do not want
to have the explicit cast.

On to the question of the .get() / .ptr() / .ref() question.

Here is the example from our code.
We have an item called the InstanceManager. It accepts a GUID and a void* of
the object. This little guy then lets other people ask for items by GUID and
then get the pointer to it. It is similar in function to CoCreateInstance,
or if you will, it is a Factory.

At any rate:

I mock up the 'object' and put it into the InstanceManager. Because I am
stuffing the actual object, and the parameter to the call RegisterQuery is
of type void* casting does not happen automatically for me; thus I must do
it myself. Observe:

TEST(foo)
{
TMockObject<IManager> mock;
InstanceManager::Instance().ReqisterQuery(GUID_IMANAGER,
static_cast<IManager*>(mock));

...

InstanceManager::Instance().UnRegisterQuery(GUID_IMANAGER);
}

It is very easy to want to type this
TEST(foo)
{
TMockObject<IManager> mock;
InstanceManager::Instance().ReqisterQuery(GUID_IMANAGER,
(IManager*)(mock));

...

InstanceManager::Instance().UnRegisterQuery(GUID_IMANAGER);
}

Which does not work.

I think it is nicer to be able to do this:
TEST(foo)
{
TMockObject<IManager> mock;
InstanceManager::Instance().ReqisterQuery(GUID_IMANAGER, mock.get()
);

...

InstanceManager::Instance().UnRegisterQuery(GUID_IMANAGER);
}

As I said before. My usage is very unusual and I do get exactly what I want
by just creating another class wrap TMockObject and provide the .get() and a
.ref() for me if I needed it. At a minimum, can we agree to do choice A,
which is to say exactly as we are, just add the operator *()?

--Kirk

-----Original Message-----
From: amop-...@googlegroups.com [mailto:amop-...@googlegroups.com] On
Behalf Of Nietz
Sent: Tuesday, June 24, 2008 11:12 AM
To: amop group
Subject: [amop-group] Re: Naming Suggestion

[Nietzsche Cheng]

Kirk:

> Firstly I think there is a little confusion: choice C plus adding the *
> operator is exactly the same as A. I wanted to emphasise that I do not want
> to have the explicit cast.

Oh I realise that now. So i think option-A is the i like,
but as i mentioned before, i feel there are a little bit asymmetric
between casting
and the * operator..from my instinct only..

anyone think that too??, and the other question, "Is it nicer to have,
or necessary ?"

[Jarl Friis]

"Kirk Korver" <kirk_...@hotmail.com> writes:

> Nietz,
>
> Please add this to the file TestMockObject.cpp. There is no problem here, I
> want it added to act as a prototype to show people how to deal with the case
> where there are more than 1 method with a same name. The solution is
> non-obvious.

Very good and illustrative example/test!!!
Great.

Jarl

[Jarl Friis]

"Kirk Korver" <kirk_...@hotmail.com> writes:

> Group,
> Yes I also see these as smart pointers. Which is why I suggested the name
> .get() to turn the actual pointer, to match the name of smart pointer
> implementations.
>
> After thinking about it, here is here is what I see as viable choices
> Choice A) Provide cast (as is, not explicit) to return pointer, and * to
> return the reference
> Choice B) provide .ptr() to return pointer, and .ref() to return reference
> Choice C) Do no change anything.

Actually I like (A) very much. But I have a fourth suggestion (mainly
to make the syntax equivalent to existing types, namely smart pointers):
Copy the syntax of shared_ptr, that is:
implement operator*() as suggested by Kirk, and implement get() to
return a pointer.

The main reason that std::string does not have implicit conversion to
char* and smart pointers don't have implicit conversions to T*, is
that those implicit conversions easily get out control. This is all
well described in "C++ Coding standards" by H. Sutter,
A. Alexandrescu, Item 40 ("Avoid providing implicit conversions"). The
overall recomendation is "Think twice before providing implicit
conversion", and "Use named functions that offer conversions instead
of conversion operator". One main reason is that when built-in types
are involved, then implicit conversion can be very hard to predict.

One reason to not follow these guidelines could be:

1) Due to the nature and purpose of TMockObject, built-in types will
NEVER be mocked, that is you will never write stuff like this
TMockObject<int>.

But is that sufficient reason to pick choice A in stead of following
share_ptr syntax?

What do you think, now that I explicitely ask you to think twice?

Jarl

[Jarl Friis]

"Nietzsche Cheng" <rdesc...@gmail.com> writes:

> Kirk:
>
>> Firstly I think there is a little confusion: choice C plus adding the *
>> operator is exactly the same as A. I wanted to emphasise that I do not want
>> to have the explicit cast.
>
> Oh I realise that now. So i think option-A is the i like,

Good, go for (A)!!! How about adding operator->() parallel to
operator*(), why not, right?

Still I would like you to answer the questions regarding keeping the
implicit conversion.

> but as i mentioned before, i feel there are a little bit asymmetric
> between casting and the * operator..from my instinct only..
>
> anyone think that too??

I don't think so. Could you explain what exactly is asymmetric?

TMockObject provide an indirect access to an object (though it is
faking), just like pointers. casting is keeping that level of
indirection, while operator* removes that indirection.

> , and the other question, "Is it nicer to have, or necessary ?"

operator* is not strictly necessary to have, but it adds natural
syntax (when provided with natural semantics) for existing standard
operators.

Put another way: If you implement operator+=(), then operator+() is
not necessary, but it would be nice to have because it provide natural
syntax for existing standard operators.

The sitution is different when we are talking about named
functions/methods, because these are always introduced.

For the same reason I will suggest implementing operator->() because
it provide natural syntax.

Jarl

[Nietzsche Cheng]

>I don't think so. Could you explain what exactly is asymmetric?

Um.. yes, if we treat TMockObject is a smart pointer, there are no
asymmetric.

> For the same reason I will suggest implementing operator->() because
> it provide natural syntax.

I totally agree (the same reason for we treat TMockObject as a smart pointer.)