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.
>