3

There are a few cases of source incompatibilities with Scala 2.8.0. For example, creating an anonymous Seq once required defining the abstract def elements : Iterator[A], which is now called def iterator : Iterator[A].

To me, a "brute force" solution is to create two branches that align to the different major scala versions.

Are there general techniques so that code like this will compile under both systems?

// Note: this code resembles techniques used by xml.NodeSeq
trait FooSeq extends Seq[ Foo ] {
   def internal : Seq[ Foo ] 
   def elements = internal.elements
   def iterator = internal.iterator // Only compiles in 2.8
                                    // need to remove for 2.7.X
}
Tristan Juricek
  • 1,804
  • 18
  • 20
  • You want to maintain a code base that is compatible with both 2.7.x and 2.8? 2.7 isn't even being maintained any more; why not take the plunge? (It's what I'm in the process of doing right now.) – Randall Schulz Jan 28 '10 at 15:30
  • The real issue is one of designing to 2.8.x features versus supporting 2.7.x versions as well. One of my hobby projects is starting to get noticed, and I want to rewrite it, and well, 2.8 is pretty nice... I'm mostly just investigating any techniques I've not considered that might make it easier to do things first in 2.8 and then make things compatible in 2.7.x, rather than the other way around. – Tristan Juricek Mar 16 '10 at 05:22

1 Answers1

2

There are a few cases where usage is simply different and you must change. But in almost all cases--such as the elements code above--the 2.7 style is simply deprecated in 2.8, not gone altogether. If you're okay leaving your 2.8 users with deprecation warnings (edit: if they compile your code, otherwise you'll just have the warnings yourself), just implement the new features in terms of the old:

def iterator = internal.elements

Otherwise, I would recommend what you call the brute force solution. Use a sufficiently clever VCS so that you don't actually have to write much code twice (Git, Bazaar, Mercurial) and branch.

Rex Kerr
  • 166,841
  • 26
  • 322
  • 407
  • Thanks, this mostly confirms my general suspicion; if you want things to be compatible with the older version, you code to the older version and eventually upgrade. Just like always. I don't know why I get these ideas in my head that new languages will reinvent this sort of behavior. Oh well - :) – Tristan Juricek Mar 16 '10 at 05:25