Open travisleithead opened 3 years ago
I had ulterior motives for this relationship; that is to be unambiguous about the character data's container. In our case that's a FormattedTextRun
in all cases, but if this feature gets integrated into DOM, it could be a Text
node. It might be a LayoutChild
object in Houdini, so a reference seemed ideal. However, I'm not sure I understand a way to do this using the immutability principle--would that be to reference an immutable copy of the text container? Or are you suggesting using a index or some other way of not directly referencing the character data container? Would love more clarity or suggestions.
However, I'm not sure I understand a way to do this using the immutability principle--would that be to reference an immutable copy of the text container?
I believe so. And to be more explicit - an immutable copy of the text container which was used for the formatting referenced by this paragraph.
In case the concern is increased memory usage / GC risk then potentially copy-on-write techniques can be applied by implementers to mitigate.
Ah. So very similar to issue https://github.com/WICG/canvas-formatted-text/issues/23
Open question on this issue is whether the metrics will provide an immutable reference to the input text, or whether the Position will need to have a looser coupling with the input than previously described (array-indexes vs object references) which may exacerbate the concerns leading to this issue in the first place.
FormattedTextPosition
- thesource
reference aFormattedTextRun
which is a mutable object (or does it reference a read only copy?). This means it might point to a run which is not the run used to format the paragraph. I think it might lead to confusion and potential bugs. Is it possible to consider a design which follows immutability principle? I assume the reason it is done like that is to reduce potential GC load but is it really such a concern compared to the risk?@nhelfman