Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.
A Type-Safe Solar System
Transcript of A Type-Safe Solar System
A gentle introduction to DSL design in Scala
SolrJ document interfaces dichotomy
"Schema-less" but we still want safety at "fields level"
Need a first working implementation ASAP
Using extensible records or row polymorphism is out of scope
First we define the operations available on a Field
Set - set a field value
Add - add a value to multi-valued field
An operation mutates a SolrInputDocument
We create a new document using `InputDocument`
But how do we know which types are supported by Solr?
Let's use the Type Class in operations
Why putting the `writer` implicit there?
Why not on the `apply` method, where it is actually needed?
Let's add some instances for types supported natively by Solr
"Well guys, that's just a Contrafunctor"
All right, let's make our Writer a Contrafunctor then!
Same approach as for writing, just simpler
That horrible casting is necessary because Solr return `Any`
Some instances for types natively supported by Solr
Wrapping SolrJ document
There is multiple ways were the schema can be beneficial for building queries
Let's integrate the schema in our Query builder
Ideally, we would be nice to support collection like syntax...
Let's put everything together, we need a model first.
But what is that `SealedObjects` thing???
A simple schema definition
Ideally, the city writer should be derived automatically
Read / Write / Query
Using immutability and laziness can have bad impact on performance.
With little changes, we can make the DSL behave in a mutable way!
No more object allocation... but more coupling and less composable.
No safety at "document level"
That is at the moment not an easy one to solve and is a subject of research ...
Very naive syntax
How can we get the best of both world?
The syntax is a bit less naive,
but still far from anything doable in vanilla scala
shapeless (scala library)
lot of crazy things!
including extensible records
type provider in macro paradise (scala)
Travis Brown schema binding (scala)
ctrex (haskell library)
vinyl (haskell library)
purescript (experimental programming language)
ADTDD ... a new fancy acronym
Basic DSL design techniques
Using Solr client for Java
Wrapping it in a Scala DSL
Available scala libraries:
Use object mapping or fully dynamic approach
Basically we went structural typing instead of nominative typing.
NOTE: The code is actually wrong!
The functions `person` and `address` should take `Address` and `Person`.
Original idea by Travis Brown:
Algebraic Data Type Driven Development
In fact it's very close to what you can do TODAY with Shapeless