I’m not 100% sure about this, and if I’m wrong that means I need to change #71 , but the spec appears to say no-ops should not be included in the count of a container, because it calls arrays with and without no-ops "considered equal". On the other hand, no-op is used as an example of a container with no data payload...
If no-ops are to be counted, then overwriting an element with them can cause the count of a container to increase, which can lead to needing more space to store the count, which leads to moving the data in the container to make room, which is both a potential cause of difficult to find bugs and against the purpose of overwriting with no-op.
So, if no-ops are supposed to be counted, they really shouldn’t be.
If they are not counted, that means that if an array has type [N], its count is meaningless because it should always be 0. Also, there’s a much shorter way to represent an empty array ( [ [ ][ ] ] ), and if one thinks of no-ops as whitespace they wouldn’t be a legal type anyway.
One of the uses of no-ops is to remove data without changing the entire file. When a large amount of data needs to be removed, that’s still a large edit because each deleted byte needs to be overwritten with [N].
So, I think it would make sense to let the sequence [ [ ][$][N][#][count] mean "ignore the next count bytes". Much faster.
Possible downsides are that this is conceptually different from for example [ [ ][$][T][#][count], and that there could be disagreement about whether the wiped data should be replaced by an empty array (in my opinion it should not). There’s also the question of what it means for an object to have type [N].
Another option to achieve the same effect is to introduce a "comment" feature, e.g. [(][#][count][data to skip] and [(][data to skip][)]. This is more elegant, but removes one or two characters from the set available for future use.
I’m not 100% sure about this, and if I’m wrong that means I need to change #71 , but the spec appears to say no-ops should not be included in the count of a container, because it calls arrays with and without no-ops "considered equal". On the other hand, no-op is used as an example of a container with no data payload...
If no-ops are to be counted, then overwriting an element with them can cause the count of a container to increase, which can lead to needing more space to store the count, which leads to moving the data in the container to make room, which is both a potential cause of difficult to find bugs and against the purpose of overwriting with no-op.
So, if no-ops are supposed to be counted, they really shouldn’t be.
If they are not counted, that means that if an array has type [N], its count is meaningless because it should always be 0. Also, there’s a much shorter way to represent an empty array (
[ [ ][ ] ]), and if one thinks of no-ops as whitespace they wouldn’t be a legal type anyway.One of the uses of no-ops is to remove data without changing the entire file. When a large amount of data needs to be removed, that’s still a large edit because each deleted byte needs to be overwritten with [N].
So, I think it would make sense to let the sequence
[ [ ][$][N][#][count]mean "ignore the nextcountbytes". Much faster.Possible downsides are that this is conceptually different from for example
[ [ ][$][T][#][count], and that there could be disagreement about whether the wiped data should be replaced by an empty array (in my opinion it should not). There’s also the question of what it means for an object to have type [N].Another option to achieve the same effect is to introduce a "comment" feature, e.g.
[(][#][count][data to skip]and[(][data to skip][)]. This is more elegant, but removes one or two characters from the set available for future use.