search

Comcast / sirius

A distributed system library for managing application reference data
http://comcast.github.io/sirius/
Apache License 2.0
298 stars 49 forks source link

Should we have native Scala external interfaces? #26

Closed comcast-jonm closed 10 years ago

comcast-jonm commented 10 years ago

Right now we have made sure that Sirius is usable from a native Java application (and hence, likely, from any JVM-targeted language), which I agree is important.

However, since Sirius is implemented in Scala, it does create an artificial awkwardness if it is used from a native Scala application, as we're essentially missing out on idiomatic Scala-isms in the interface in that case.

Should we have two sets of external interfaces? One targeted at Scala-native users, and one targeted at Java and everything else? Please discuss.

smuir commented 10 years ago

This is somewhat orthogonal, but perhaps not entirely, to issue #19, yes?

comcast-jonm commented 10 years ago

I think that's right (mostly orthogonal).

clinedome-work commented 10 years ago

I'd lean no. I'd say a single tidy, understandable, predictable interface for everyone has a lot of value. I'd rather not add bells and whistles to make things idiomatic for a subset of folks using the library, just because they happen to be using the same language that the library was written in. I feel like there be dragons thataway. I'd prefer simple.

mbyron01 commented 10 years ago

I'm of two minds on this one. I think what we have is the cleanest solution but I could see a need for a Scala native interface in the future. So I would say no for now and if the interest or demand for an additional interface arrises then that would be a good feature to add to sirius.

comcast-jonm commented 10 years ago

Ok, I'm a YAGNI-kind of guy anyway, so I'll vote 'no for now' too.

tbarker9comcast commented 10 years ago

This is not directly related, but I noticed that intellij struggled with groovy interoperability against the scala interfaces. I didn't really care since I thought sirius was primarily targeting java and scala; the script is also quite small, so a text editor is sufficient. If there was a java interface this probably would not be a problem.

So.... if interoperability is important beyond java and scala, pure java interfaces could make life easier; java is the lowest common denominator. Going forward with new projects, maybe we should include java interfaces to ensure smooth interoperability? Now all of this said, I would imagine someone might prefer to throw some thin http layer around sirius much like the reference application.

mattinger commented 10 years ago

I would say it makes sense to keep Sirius itself very scala-y and write a java-ish wrapper around it to deal with thinks like Runnable, java types, etc....

It's not unheard of. rx-java is written entirely in java, and they have the rx-java-scala wrapper around that to take advantage of scala-isms.

I see no reason we can't do it in the opposite direction.

On Thu, Feb 13, 2014 at 2:04 PM, tbarker9comcast notifications@github.comwrote:

This is not directly related, but I noticed that intellij struggled with groovy interoperability against the scala interfaces. I didn't really care since I thought sirius was primarily targeting java and scala; the script is also quite small, so a text editor is sufficient. If there was a java interface this probably would not be a problem.

So.... if interoperability is important beyond java and scala, pure java interfaces could make life easier; java is the lowest common denominator. Going forward with new projects, maybe we should include java interfaces to ensure smooth interoperability? Now all of this said, I would imagine someone might prefer to throw some thin http layer around sirius to ensure much like the reference application.

Reply to this email directly or view it on GitHubhttps://github.com/Comcast/sirius/issues/26#issuecomment-35013164 .