search

sbt / sbt-remote-control

Create and manage sbt process using unicorns and forks
Other
74 stars 14 forks source link

Remove custom PrimitivePicklers #247

Closed eed3si9n closed 9 years ago

eed3si9n commented 9 years ago

This creates type aliases for the following picklers:

VectorPicklers, ListPicklers, ArrayPicklers, and SeqPicklers are still needed for emitting $type hints on each element.

jsuereth commented 9 years ago

@eed3si9n can you rebase these?

havocp commented 9 years ago

We could drop the type aliases right? my general feeling is that to write a handcoded pickler or custom "pickler cake" you'd use pickling directly, and that our job in sbt.serialization is to prebake one possible set of defaults (staticonly, remove format customizability) and give a convenient way to import those defaults. But I guess this philosophical issue is what we need to discuss on Monday. I'm fine with not holding up this PR over those aliases. I don't currently understand the serialization vs CoreProtocol split.

havocp commented 9 years ago

PR looks good otherwise but raises obvious question of can we modify pickling itself to give the necessary info for $type support.

jsuereth commented 9 years ago

where is it we want the $type that's causing issues? Each underlying element? That should be determined by the nested pickler anyway....

eed3si9n commented 9 years ago

I think I used to call pickler, but the new JSON format might be using builder directly. Not sure if that changes anything.

jsuereth commented 9 years ago

Ok, let's merge this as is. I'd like to understand what's happening with the array picklers though.