mockobjects-java-dev

[MO-java-dev] dynamic branch and merge

[Steve F. <st...@m3...>]

folks, given that some people aren't totally happy with nat's branch,
how about we start implementing the few bits we agree on in the HEAD?
For example, adding the ActiveCall object. That way we can make /some/
progress and the merge will be less painful.

S.

RE: [MO-java-dev] dynamic branch and merge

[Vincent M. <vm...@pi...>]

Is this going to break the DynaMock API from released version 0.09?

In any case I believe we should absolutely provide backward
compatibility and mark changed methods as deprecated. All new public
methods should also be tagged with the "@since" javadoc tag.

Thank you
-Vincent

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...] On Behalf Of
> Steve Freeman
> Sent: 03 July 2003 01:25
> To: moc...@li...
> Subject: [MO-java-dev] dynamic branch and merge
> 
> folks, given that some people aren't totally happy with nat's branch,
> how about we start implementing the few bits we agree on in the HEAD?
> For example, adding the ActiveCall object. That way we can make /some/
> progress and the merge will be less painful.
> 
> S.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev

Re: [MO-java-dev] dynamic branch and merge

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

I think it will be very hard to provide complete backwards compatability.
Changing the dynamock library to use the ActiveCall class will change the
Callable method, and thereby change every class that implements or calls
Callable.

If you just use the Mock class and the sugar methods it will be possible.
In my branch I renamed some of the classes and sugar methods so that they
follow a regular system of names -- I found that less confusing.  I'm sure
we can use deprecated and overloaded methods to provide backwards
compatability here.

For example, instead of "expect" I used "expectVoid" to expect a void
method.  I used "expect" to expect a user-defined stub.

Regards,
            Nat.
_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661

----- Original Message -----
From: "Vincent Massol" <vm...@pi...>
To: "'Moc...@Li...'"
<moc...@li...>
Sent: Thursday, July 03, 2003 9:36 AM
Subject: RE: [MO-java-dev] dynamic branch and merge


> Is this going to break the DynaMock API from released version 0.09?
>
> In any case I believe we should absolutely provide backward
> compatibility and mark changed methods as deprecated. All new public
> methods should also be tagged with the "@since" javadoc tag.
>
> Thank you
> -Vincent
>
> > -----Original Message-----
> > From: moc...@li...
> > [mailto:moc...@li...] On Behalf Of
> > Steve Freeman
> > Sent: 03 July 2003 01:25
> > To: moc...@li...
> > Subject: [MO-java-dev] dynamic branch and merge
> >
> > folks, given that some people aren't totally happy with nat's branch,
> > how about we start implementing the few bits we agree on in the HEAD?
> > For example, adding the ActiveCall object. That way we can make /some/
> > progress and the merge will be less painful.
> >
> > S.
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> > Data Reports, E-commerce, Portals, and Forums are available now.
> > Download today and enter to win an XBOX or Visual Studio .NET.
> >
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev

RE: [MO-java-dev] dynamic branch and merge

[Vincent M. <vm...@pi...>]

Hi Nat,

> -----Original Message-----
> From: Nat Pryce [mailto:nat...@b1...]
> Sent: 03 July 2003 12:17
> To: Vincent Massol
> Subject: Re: [MO-java-dev] dynamic branch and merge
> 
> I think it will be very hard to provide complete backwards
compatability.
> Changing the dynamock library to use the ActiveCall class will change
the
> Callable method, and thereby change every class that implements or
calls
> Callable.

Just as long as it as the user public API is the same it is fine. BTW,
do we have a strategy so that users know what is public from what is
not?

What I am doing on my new projects is to include the keyword "internal"
for non-public packages. For example:

org.apache.cactus                    <-- public
org.apache.cactus.server             <-- public
org.apache.cactus.internal           <-- non public
org.apache.cactus.internal.server    <-- non public
[...]

[Note: I have taken this from Eclipse]

The strategy is then that we are not allowed to break public APIs
between subsequent releases. However items can be marked as deprecated
and new API introduced. We then keep deprecated classes/methods for at
least 2 releases and we are then free to remove it.

However for internal classes, we are free to change the implementation
whenever we want (of course provided the functional/acceptance tests
still pass).

> 
> If you just use the Mock class and the sugar methods it will be
possible.

Cool. I think I'm only using "terminal" APIs from DynaMock.

> In my branch I renamed some of the classes and sugar methods so that
they
> follow a regular system of names -- I found that less confusing.  I'm
sure
> we can use deprecated and overloaded methods to provide backwards
> compatability here.
> 

excellent.

> For example, instead of "expect" I used "expectVoid" to expect a void
> method.  I used "expect" to expect a user-defined stub.

That's fine, provided we mark the expect method as deprecated and not
remove it for a while.

Thanks 
-Vincent

> 
> Regards,
>             Nat.
> _______________________
> Dr. Nathaniel Pryce
> B13media Ltd.
> http://www.b13media.com
> +44 (0)7712 526 661
> 
> ----- Original Message -----
> From: "Vincent Massol" <vm...@pi...>
> To: "'Moc...@Li...'"
> <moc...@li...>
> Sent: Thursday, July 03, 2003 9:36 AM
> Subject: RE: [MO-java-dev] dynamic branch and merge
> 
> 
> > Is this going to break the DynaMock API from released version 0.09?
> >
> > In any case I believe we should absolutely provide backward
> > compatibility and mark changed methods as deprecated. All new public
> > methods should also be tagged with the "@since" javadoc tag.
> >
> > Thank you
> > -Vincent
> >
> > > -----Original Message-----
> > > From: moc...@li...
> > > [mailto:moc...@li...] On
Behalf Of
> > > Steve Freeman
> > > Sent: 03 July 2003 01:25
> > > To: moc...@li...
> > > Subject: [MO-java-dev] dynamic branch and merge
> > >
> > > folks, given that some people aren't totally happy with nat's
branch,
> > > how about we start implementing the few bits we agree on in the
HEAD?
> > > For example, adding the ActiveCall object. That way we can make
/some/
> > > progress and the merge will be less painful.
> > >
> > > S.
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email sponsored by: Free pre-built ASP.NET sites
including
> > > Data Reports, E-commerce, Portals, and Forums are available now.
> > > Download today and enter to win an XBOX or Visual Studio .NET.
> > >
> >
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> > > _______________________________________________
> > > Mockobjects-java-dev mailing list
> > > Moc...@li...
> > > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Free pre-built ASP.NET sites
including
> > Data Reports, E-commerce, Portals, and Forums are available now.
> > Download today and enter to win an XBOX or Visual Studio .NET.
> >
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev

Re: [MO-java-dev] dynamic branch and merge

[Steve F. <st...@m3...>]

Folks (and especially Vincent). I've been trying to find a way to break 
through the morass of overloading to come up with a cleaner API for the 
dynamics and it's not easy to do it incrementally. Maybe I'm just too 
tired, or need a pair, but the backwards compatibility is getting in the 
way.

I know Vincent's written it up in his book, but is there anyone else 
that an API change would hurt? Or a way to do it under the covers?

S.

Vincent Massol wrote:
> Is this going to break the DynaMock API from released version 0.09?
> 
> In any case I believe we should absolutely provide backward
> compatibility and mark changed methods as deprecated. All new public
> methods should also be tagged with the "@since" javadoc tag.

Re: [MO-java-dev] dynamic branch and merge

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

It'll hurt some of my projects, but I'm willing to defer a move over to a
new API for some projects and try out a new API on others.

I'd love to see a way to alleviate the overloading hassle.  Tim's idea of
creating "expected call" objects that you can add arguments and return
values to seems a good way to go.  However, I've found the decorator
architecture incredibly flexible and I'm not sure if separating matching
from expectations will be a good way to go.

For example, I've recently been writing a structured graphics framework.
One thing I need to test is the drawing order of layered graphics: elements
should be drawn in their z-order.  So I mock each layered element and expect
draw calls.  However, this does not test the order of calls: I need a call
sequence that crosses multiple mocks.  This is trivial to do with decorators
because they have both a match and call method. It would be hard to do if
the two methods are in separate objects.  (I can provide more details if
anybody is interested).

Cheers,
            Nat.

_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661

----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: "Vincent Massol" <vm...@pi...>
Cc: "'Moc...@Li...'"
<moc...@li...>
Sent: Tuesday, July 22, 2003 12:00 AM
Subject: Re: [MO-java-dev] dynamic branch and merge


> Folks (and especially Vincent). I've been trying to find a way to break
> through the morass of overloading to come up with a cleaner API for the
> dynamics and it's not easy to do it incrementally. Maybe I'm just too
> tired, or need a pair, but the backwards compatibility is getting in the
> way.
>
> I know Vincent's written it up in his book, but is there anyone else
> that an API change would hurt? Or a way to do it under the covers?
>
> S.
>
> Vincent Massol wrote:
> > Is this going to break the DynaMock API from released version 0.09?
> >
> > In any case I believe we should absolutely provide backward
> > compatibility and mark changed methods as deprecated. All new public
> > methods should also be tagged with the "@since" javadoc tag.
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev

RE: [MO-java-dev] dynamic branch and merge

[Vincent M. <vm...@pi...>]

Hi Steve,

> -----Original Message-----
> From: Steve Freeman [mailto:st...@m3...]
> Sent: 22 July 2003 01:01
> To: Vincent Massol
> Cc: 'Moc...@Li...'
> Subject: Re: [MO-java-dev] dynamic branch and merge
> 
> Folks (and especially Vincent). I've been trying to find a way to
break
> through the morass of overloading to come up with a cleaner API for
the
> dynamics and it's not easy to do it incrementally. Maybe I'm just too
> tired, or need a pair, but the backwards compatibility is getting in
the
> way.

I've found that API compatibility is a mentality issue and not a
technical one. If you do care about API compatibility then you'll be
able to keep the compatibility (in several cases, it means restricting
your refactoring changes and spreading them over releases). OTOH if you
don't care much then everything is possible but then you may anger your
users.

My personal opinion is that mockobjects should have released a 1.0
version a long time ago and should be *stable* and care about API
compatibility. Refactoring is nice to do but not when it comes to
API-public parts. One other thing that we're not doing correctly I
believe, is to warn users when we consider an API not to be stable and
they should not use it in production project (i.e. they should just play
with it). Naming it 0.09 is not a solution as this has been going on for
several years now... so it makes no difference as if it were version
6.0.

I've recently discovered that your choice about design should not be
only driven by the beauty of OO constructs but also for extensibility in
the compatibility sense (a good article:
http://www.eclipse.org/eclipse/development/java-api-evolution.html). In
other words you should design frameworks, so that they can be modified
without breaking the user-public APIs. I did the mistake on Cactus of
not knowing about this and we're correcting my mistake slowly as we go.
"Internal" classes should be clearly identified and binary compatibility
should be taken into account (see
http://blogs.codehaus.org/people/vmassol/archives/000098.html).

Thanks
-Vincent

> 
> I know Vincent's written it up in his book, but is there anyone else
> that an API change would hurt? Or a way to do it under the covers?
> 
> S.
> 
> Vincent Massol wrote:
> > Is this going to break the DynaMock API from released version 0.09?
> >
> > In any case I believe we should absolutely provide backward
> > compatibility and mark changed methods as deprecated. All new public
> > methods should also be tagged with the "@since" javadoc tag.
>