Dear Contributors,
With a bit of delay, here comes the SPP Meeting Minutes from November 27th, 2017:
- Catching up on updates since our previous meeting: Scala Platform infrastructure, policies, and roadmap for 2.13.x.
YouTube time: 00’00’'
Jorge gives a brief status update on the progress between the two SPP meetings.
Notably the Better files and Scala JSON AST, both libraries had active contributions and productive discussions.
He points out that Scala 2.13 release is scheduled for 27. April 2018 and that Scala Platform should have its release before that (ideally January / early February 2018).
He later adds that the list of deprecated modules is not yet final but that there are talks about certain modules like scala.concurrent, scala.io, scala.sys scala.runtime, scala.util, scala.text… (more about these changes SIP meeting 2017 YouTube link minutes).
The SPP Committee should make a decision about which of those modules should become a part of the Scala Platform.
Many questions were raised throughout the meeting about SP and SPP:
Eugene asks Jorge (YouTube time 3’15’’) to give a general overview of the SPP and explain if SPP is the one or one of many possible platforms in the future?
(In the following part I will summarise the main points and the subjects related to this question. Please note that I extracted them from various parts of the meeting and bundled them up under the “SPP general points to discuss category” (below) all points were mentioned but not decided upon and will be spoken about in the future SPP meetings.)
- As of Scala 2.13 release in April 2018, many libraries will be deprecated, meaning Scala Team at Lightband will not keep maintaining them.
- Scala Platform is an answer to the modularisation of the language.
- The modules in Scala Platform should support only the last 2 versions of Scala
- It is one of the possible platforms, it’s unique in its choice of the content but not in its existence
- The objective is to create and collaboratively maintain a reliable, established and simple to use/learn infrastructure = Scala Platform, aside from the Core language.
- The spirit of “the least powerful abstraction”
SPP general points to discuss and some ideas:
a) which libraries should be a part of the Platform
b) keep contributors active within the Platform
c) find a way to entice the companies to help support contributors
d) develop a migration tooling/guides: how is the process actually going to unfold
(see Rex’s argument at 12’27’’ - 16’10’’)
e) IDEA: create a “minimal validation library” that other libraries could integrate.
(mentioned by Jorge)
f) IDEA: eventually provide a “style guides” and “standards” (see Aleksandar’s argument at 26’35’’ and Jorge’s suggestion at 32’37’’)
- A final vote on Better Files and updates on Scala JSON AST.
Pathikrit makes an introduction about what are and Better Files and the motivation.
It’s targeting the common file utiles (like read, write, move directory, copy and other) for those who want to do IO in Scala, as "it is not obvious how to do those in java"
Better Files is a wrapper around java.io.file
In the meantime, it became it’s own Scala library, thanks to adding utiles to it.
The work is inspired by Google’s Guava and Apache’s IOUtiles.
More at https://github.com/pathikrit/better-files
After taking a closer look, Eugene (YouTube time: 19’40’’) goes into technical details to which Pathikrit explains how the issues evolved, basically pointing that issues pointed out by Eugene are already addressed, one is resolved and the other is on its way.
Rex agrees it is a good idea to have “parameters each time in the methods”.
Others agree the Better Files are useful and needed a part of the Platform.
Conclusion: The module is accepted as a part of Scala Platform by a unanimous vote.
- Discussion of the proposal “Make Scala Platform API independent of Java namespaces”
Eugene’s opens the topic with the observation that the proposal is a bit confusing, and he tries to understand what is it aiming to do (YouTube time: 37’)
Option 1 - moving some stuff to a scala namespace (like a date)
Option 2 - standard tooling like a compiler and sbt will only depend on scala namespace and not use the java namespace, what exact problem is it trying to solve?
Or is this proposal philosophical/aesthetic?
Jorge: it asks for re-implementing the JDK utilities in the Scala with a goal to directly cross compile, so that Scala supports and Java doesn’t.
Concluding that with different runtimes there needs to be a team working on it full time.
The communities that benefits the most are Scala JS users and Scala Native (the further would not need to re-implement IO or NIO as they do right now)
Lars makes a point on if Scala Native and Scala JS don’t share the same code, this proposal makes no sense, Jorge adds it should be discussed another time and ask the proposal authors to join.
Rex (YouTube time: 44’45’’) doesn’t think that the proposal addresses the difficult part of the problem - the underlying differences between the platforms. It could solve a less difficult part of the problem, but it’s not worth the effort.
Jorge agrees with Rex and adds that it would need a more balanced proposal as it would be great having something cross-platform on the Scala Platform.
Aleksandar (YouTube time 53’24’’) suggests, given that Committee is supposed to define the minimal API than the maintainers of those specific backend or compiler versions should be the one that tests it.
He points out that the biggest advantage of this proposal is introducing the Scala namespace gives a certainty that it might be supported in the future.
Bill proposes to have naming by packages showing which libraries work on which platform e.g “library x JVM only” so it is easier to keep track of which libraries work across platform and which don’t.
Conclusion: This proposal is interesting but there needs to be more discussion and clarity before moving forward.