Right. First one has to understand the „list of piece“ idea behind Texts.Text, then you can deep dive into the implementation of pieces. Whether pieces are direct buffers in memory or text stretches in files is (for the helicopter view) not so important. Jörg
Am 28.07.2018 um 12:52 schrieb Josef Templ <josef.templ@gmail.com>:
if I remember correctly, you should not think of the text pieces as in memory text blocks but as references to text stretches on files. A piece is always on a file and has a start pos and a length. The length can exceed the main memory. Only a part of the file will be kept in memory, depending on the buffering strategy in module Files. This allows, in principle, editing texts that are larger than the main memory. It also allows for a lot of sharing. If you copy a text then the piece list will be copied but the pieces will refer to the same file and position. The pieces are treated read-only for that. It also allows to open texts quickly because not all of the contents will be read into main memory.
- Josef -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon