-
-
Save dherman/4265013 to your computer and use it in GitHub Desktop.
var IPAddress = new ArrayType(uint8, 4); | |
var P_IPAddress = new PointerType(IPAddress); | |
var Packet = new StructType({ addr: IPAddress, ... }); | |
var P_Packet = new PointerType(Packet); | |
var PacketArray = new ArrayType(Packet); | |
var lotsOfPackets = new PacketArray(LOTS); | |
for (let p of lotsOfPackets.cursor("addr")) { | |
... | |
} |
+-------------+ +-----------------------+ | |
| |---------->| | | |
| PointerType | | PointerType.prototype | | |
| |<----------| | | |
+-------------+ +-----------------------+ | |
^ | |
| | |
| | |
+-----------------------+ +-------------+ | |
| |---------->| | | |
| T | | T.prototype | | |
| |<----------| | | |
+-----------------------+ +-------------+ | |
^ | |
| | |
| | |
+-------------+ | |
| | | |
| p | | |
| | | |
+-------------+ |
b ::= int8 | uint8 | int16 | uint16 | int32 | uint32 | float32 | float64 | |
t ::= b | s | *s | |
s ::= [t x k] | { x1: t1, ..., xn: tn } |
Ok, now I think I understand what's going on here. In the StructView
approach, cursors can only point to instances of struct types. Which means that if you want to iterate over fixed-length, uniform data, you have to write it out as a struct, rather than using an array.
But this raises the question of why nominal typing is ok for structs but not for arrays, since we've just seen that they're interchangeable here. We could structurally type structs, in which case StructView
has exactly the same perf costs, or we could nominally type arrays, so everything is fast even in the PointerType
version. Right?
The issue is just that it seems stranger for different array types to be non-interchangeable than for different struct types, right?
The issue is just that it seems stranger for different array types to be non-interchangeable than for different struct types, right?
Right.
But more broadly, it also violates expectations if updating a pointer involves an O(n) check (where n is the size of the type, not the data structure, but still). So I really wanted to avoid structural type checks.
(Another way to look at it: we could imagine calling it
PropertyView
instead ofStructView
, and then it would make sense to allow it to point to properties of either struct or fixed-length array type. Then there'd be no meaningful difference between the two designs, and we'd be back to having to do a structural type check. The names are significant here; I'm trying to nail down the right conceptual design for the abstractions, not just the observable semantics.)