By inheritance, elasticsearch.ProjectionConstants exposes impossible things:
DOCUMENT: it's a Lucene document but that's not available and can be confused with SCORE: should we remove SCORE and map DOCUMENT to SCORE for the es backend?
DOCUMENT_ID: does ES expose a document id?
EXPLANATION: does Expose an explanation object? Same type as Lucene's?
I wouldn't bother too much about this. +1 for strictly separating the two interfaces, as it will take away "wrong" constants from auto-completion. This should be fine to address most common usage mistakes.
Ok, let's go for the separation for our first Elasticsearch supporting release, but my question about how this API could be better stands for version 6 .. in case any of you have ideas I opened to see if something could be done.
Some meta comment. In the grand scheme of better output for the current people working on the project, we probably should not focus too much on nice details and settle for good enough. I'm the first to be saddened by a non type-safe approach but we know it costs several days of engineering to reach this at the very list. Damn economics!
Ack. Let's keep the fur on this yak and shave it another day.
Sure but this is no different than what I already planned: is scheduled for 6, and wasn't proposing it as a blocker.
It's just an invitation to comment on that issue, if you happen to have a good idea.