voddan07/22/2019, 1:44 PM
Chuck Jazdzewski [G]07/22/2019, 4:00 PM
1) ... structural limitationsNo. The data structure is an internal detail. We could switch to a different data structure if performance dictates. We have already switched twice before we went public.
2) What sources and methods ....Mostly experience with many different frameworks over our careers (for me personally this is my 6th framework). This, however, is just an observation and is not required for the performance of the system. Compose can handle large radical changes in the UI just a easily but we are optimizing around localized changes as that is what we believe will be most common.
3) Do you know of any use cases that are atypical for....Yes. Inserting and removing nodes at the beginning and end of the slot table in the same composition or any other form of non-local change. As the slot table is a flattening of the of a tree, any non-local changes to the tree will cause copying of the array as the buffer gap moves. If this is common we can introduce multiple gaps or using an internal tree; but, for now, we have a flat array with a single gap.
4) ...how hard will it be to switch...Not hard. We are keeping the data structure internal and only exposing an abstraction to the code generation to call. We have switched the implementation twice already without impacting the programming model. Even if the code generation takes a more active role (such as producing a scope record to avoid boxing) we still anticipate using the same API as the scope record could just be stored a
like call. We do plan some significant surface changes to the API, moving to a more of a code-flow approach instead of call interception, as explain in Leland's talk which will result in changes to the API the compiler uses but it will still be abstract enough to hide the flat vs. tree based data structure.
voddan07/23/2019, 12:59 AM