On 31 Jan 2013, at 11:53, Manik Surtani wrote: > > On 31 Jan 2013, at 11:45, Mircea Markus <[email protected]> wrote: > >> Hi, >> >> >> The REST module is written in Scala (both main + tests). We have some *test* >> contributions written in Java (thanks mlinhard). >> There was an IRC discussion on whether it's worth migrating the Java >> contribution to Scala code or not. >> >> Pros for migrating the contribution from Java to Scala: >> - the REST module is written in Scala. Contributing these tests in Java >> would make the module bi-lingual, potentially confusing future contributors > > Why? You can choose what to write your tests in. > >> - even though this is not the case with this particular contribution, there >> might be code duplications between the scala test suite and java test suite. > > Don't create separate test suites. Put them in the same class path - e.g., > src/test/scala - you can have .java files in here too, they will be compiled > together, run together, can reference one another. > >> >> Cons for migrating the contribution from Java to Scala: >> - there are contributors that are not familiar with Scala or are more >> proficient with Java(such as mlinhard). Forcing them to contribute in a >> language they are not familiar with would put them off > > +1 > >> - my general feeling over time was that people (including me) are not very >> enthusiastic about debugging and extending Scala code. So IMO if there's a >> choice between scala and java (in the scope of the scala modules) we should >> stick to Java wherever possible (such as this contribution). > > That should not be a hard and fast rule for all modules. I agree that some > modules (like core) should just stick to Java.
I don't think that encouraging scala code is good purely for maintenance reasons. If there's a choice, it should be java. Not saying that learning a new language is not cool - but in practice people are a bit put off by maintaining Scala code. Its not only about what the writer of the code prefers as a language: it's more important what the maintainers of the code will has to work with. Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org)
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
