Scala.js Status

[phaller]

Development branch: https://github.com/phaller/pickling/tree/topic/js

[andreaTP]

I'll try to summarise here thoughts on this topic:

What is needed to keep pickling working seamlessly in the scala.js world we will need: 1- a compiler plugin to substitute java Serializable interface to a custom JSSerializable and to mark classes that needs to be pickled. 2- a macro to generate real picklers/unpicklers that will rely on stubbed methods for accessing and modifying private fields. 3- an IR manipulation build step that will generate hidden methods to access private/protected fields in runtime based on the list provided by the previous plugin.

Based on that it will be possible to replicate the behaviour of reflective picklers on different JVMs.

Comments, ideas and suggestions are a lot appreciated from @sjrd , @yawnt and anyone else can be helpful on the topic!

[jsuereth]

@phaller Hey, we may be stepping on each other here. I actually have a branch I'd like you to look at where I completely redo the backend of pickling, and I'm working on a new mechanism for the macro-code-generators:

New backend - https://github.com/scala/pickling/tree/wip/new-macro-implementation/core/src/main/scala/scala/pickling/spi

New Macros - https://github.com/scala/pickling/tree/wip/new-macro-implementation/core/src/main/scala/scala/pickling/generator

@phaller do you have time to sync up sometime soon on our work and see if we can merge? I'm almost at the point the new macros can replace the older ones (but with added static-only stability).

Thanks!

• Josh

[phaller]

@jsuereth Hey Josh, syncing up sounds great. I'll be in transit/busy tomorrow, but after that we could also schedule a call.

My motivation for this branch is Scala.js support, obviously, but I did discover a few improvements that would be useful in general. In particular, I think we can simplify FastTypeTag significantly, and get rid of its dependency on run-time reflection completely (essentially, we only need its compile-time generated string representation). Though, it requires changing its public API, so it would have to go into 0.11.x.

Also, I have a suspicion that the start-up delays might be due to the initialization of a large number of FastTypeTags, since it turns out we are using the run-time-reflection-based way of creating FastTypeTags in some places, which involves heavy run-time reflection. Again, not because it's necessary, but because the current API makes it convenient.

Otherwise, I did not really work on the backend or macros. The goal here has been to make pickling work on Scala.js with only minimal changes (to share code as much as possible). So, it might not be that difficult to reconcile our branches, actually.

[phaller]

@jsuereth Btw, my proposal for the new FastTypeTag is called StaticTypeTag on my topic/js branch. No particular reason for renaming it. In fact, I was about to add a commit which renames it back to FastTypeTag, so that the topic/js branch could be more easily compared to the mainline 0.10.x and 0.11.x branches. (Actually, the branch cannot be compared as is, only individual files, since it contains a copy of the source for now.)

[jsuereth]

@phaller The new FastTypeTag sounds GREAT. I'd love to see those changes. My changes also require a 0.11.x because of breaking some semantics with past macro generated pickler/unpicklers.

In any case, I'm on G+ and gitter, ping me when you have time. Would love to catch up.

[jvican]

Is there still interest in refactoring TypeTag or has already been done in v0.11.x?

[phaller]

@jvican I am still very much interested in this refactoring. AFAIK it has not yet been done in 0.11.x.

[jvican]

Nice, I think it's a great idea and I'd love to see it working :+1:

[andreaTP]

:+1: :+1: :+1: