Kotlin Project Model Design Documentation 1.0-master Help

Solved design questions

This page is meant to keep track of design decisions and motivation behind them

Variant as a “set of fragments” vs. variant as a “special case of a fragment”

Alternative option:

Variant- a set of complete API surface exposed by a module, expressed by set of exposed Module Fragments (we’ll also interchangeably say that “the fragment contributes to/participates in” if the fragment belongs to that set). “Complete” here means that all expects receieved their actuals.

Fragments in variants are closed under Refines-relation: if the fragment F participates in variant V, then the whole transitive closure of F over refines-edges must belong to V as well. Therefore, variant might be defined just by set of “leaf” fragments, as the remaining transitive closure can be restored easily.

Decision: currently declined

Motivation: the essential difference from the currently accepted definition is whether variant can have several disjoint leaf fragments. Using our usual examples, it would theoretically allow variants which consist of, say, jvmMain and jsMain. Obviously, the jvmMain + jsMain option is incorrect and needs some additional rules for ridding such cases out. Moreover, we don’t know the exact cases which would need that, so for now we just use more restrictive definition.

Last modified: 20 May 2021