-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ExtractionFacade.supports to improve on language composition #65
Conversation
07dcd49
to
61e42aa
Compare
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. |
I like to think the In this case - the See e.g. the new implementation of the Would it be helpful to work out how different kinds of language composition would play out after adding the |
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. |
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 So, ould it be helpful to work out how different kinds of language composition would play out after adding the supports to |
My point is, that this is only relevant in the With this "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 |
61e42aa
to
75ec2f5
Compare
Jos and I came to the same conclusion yesterday. We agreed this warrants some more thinking about how language compose in various ways.
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.
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 |
065bf8f
to
125fc6c
Compare
0ee2f41
to
4561c48
Compare
8753bcd
to
ff8294f
Compare
ff8294f
to
dfd3f4e
Compare
To discuss through this PR.