On 31 Jan 2013, at 11:53, Manik Surtani wrote:
On 31 Jan 2013, at 11:45, Mircea Markus <mmarkus(a)redhat.com> 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)