Well the no-arg ctor will be using Version.getDefault() which will throw an exception if not set, and delegate the call to the Version-aware ctor.
On Tuesday, April 13, 2010, Robert Muir <rcm...@gmail.com> wrote: > On Tue, Apr 13, 2010 at 11:27 AM, Shai Erera <ser...@gmail.com> wrote: > > > I was thinking that we can add on Version a DEFAULT version, which the caller > can set. So Version.setDefault and Version.getDefault will be added, as > static members (more on the static-ness of it later). We then change the API > which requires Version to also expose an API which doesn't require it, and > that API will call Version.getDefault(). People can use it if they want to ... > > I don't understand how this works... if Something has a no-arg ctor today, > and i want to improve it in a backwards-compatible way, how will this work? > the way this works today, lets say while working with 3.1 is: > > Something() is deprecated, and invokes Something(3.0)Something(Version) is > added, and emulates the old behavior for < 3.1, and the new behavior for >= > 3.1 > i dont see how backwards compatibility will work with this proposal, since > the no-arg ctor would then emulate some random behavior depending on a static. > > > -- > Robert Muir > rcm...@gmail.com > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
