Add ExtractionFacade.supports to improve on language composition

[dslmeinte]

To discuss through this PR.

[woppa684]

So, for my understanding, this is just a helper function to not run into decoding issues later, right? Without it, everything would work exactly the same, but you would maybe get weird errors later in the process.

[dslmeinte]

I like to think the supports function is more than "just" a helper function. Essentially, api.supports(node) === true says: "node can be seen as belonging to the language that api is for". This should help with combining (AKA "composing") languages, because there's a bunch of ways that languages can be composed.

In this case - the multi language -, it is extension because we just add a new concept without altering existing concepts. But that's not the only way of composition.

See e.g. the new implementation of the conceptOf function in the ReadModelAPI for the multi language: it now checks first which language the node belongs to, rather than assuming that node belongs to the extending language if it doesn't belong to the extended language.

Would it be helpful to work out how different kinds of language composition would play out after adding the supports to ReadModelAPI?

[woppa684]

See e.g. the new implementation of the conceptOf function in the ReadModelAPI for the multi language: it now checks first which language the node belongs to, rather than assuming that node belongs to the extending language if it doesn't belong to the extended language.

Sure, but this is all in the "client domain". If this method would not have been present on the API, a user would have been able to easily implement something similar by himself. As far as I can see, the only place where the internals of the core use it, is in the serializer to throw an early error when a node is not supported.

[dslmeinte]

For serialization chunks ("serialized models") there is no issue with language composition: every serialized node has a meta-pointer to the exact right concept/feature(/annotation). So, language composition is essentially only "happening" on the client anyway. Essentially, it's a matter of mapping runtime types to concepts and back again. (Even for deserialization, that only means instantiating a given concept as a particular runtime type.)

The supports function makes it explicit whether the runtime/client-side (read-)API for a particular language "owns"/recognizes a particular node.

So, ould it be helpful to work out how different kinds of language composition would play out after adding the supports to ReadModelAPI?

[woppa684]

My point is, that this is only relevant in the conceptOf function of the API, and it's up to the client (of this library, so not the frontend code as client) to implement that in the correct way. A supports function COULD assist in that, but is not mandatory to have a perfectly fine API implementation.

With this supports function you're prescribing "the client" to implement multiple APIs (one per language) but access them via a single one when serializing. This does not need to be the best implementation for a specific client of this library. I can imagine that you could, for example, encode the Language as a string field in the "BaseNode" of a certain language. In that way, the conceptOf function could also be implemented easily without supports.

"owns" and "recognizes" are to different things of course. With the pattern you want to enforce, you do expect the ReadAPI of a Language to also "recognize" its used languages, right? So, for me, that would just mean that its conceptOf function would not throw an error when serializing and the supports does not add much, what if it doesn't? Then still the serialization will fail right? supports should fail when conceptOf would fail if called, it's just a heads-up.

[dslmeinte]

With this supports function you're prescribing "the client" to implement multiple APIs (one per language) but access them via a single one when serializing. This does not need to be the best implementation for a specific client of this library.

Jos and I came to the same conclusion yesterday. We agreed this warrants some more thinking about how language compose in various ways.

I can imagine that you could, for example, encode the Language as a string field in the "BaseNode" of a certain language. In that way, the conceptOf function could also be implemented easily without supports.

That'd be a possibility we've vehemently rejected several times already. String values (IDs, keys) should not be parsed for some kind of semantics - instead, they should be taken as values as a whole. If we'd really need the extra info, we should just make an extra field.

"owns" and "recognizes" are to different things of course. With the pattern you want to enforce, you do expect the ReadAPI of a Language to also "recognize" its used languages, right? So, for me, that would just mean that its conceptOf function would not throw an error when serializing and the supports does not add much, what if it doesn't? Then still the serialization will fail right? supports should fail when conceptOf would fail if called, it's just a heads-up.

I'm trying to get rid of exceptions throughout, since they're essentially unrecoverable faults. I'd rather use a FP-style. But indeed: the conceptOf could signal its failure in some way and then supports(node) === false is exactly the same as conceptOf(node) === null (or some other sentinel value).