Skip to content

Instantly share code, notes, and snippets.

@dherman
Created December 12, 2012 05:04
Show Gist options
  • Save dherman/4265013 to your computer and use it in GitHub Desktop.
Save dherman/4265013 to your computer and use it in GitHub Desktop.
pointer type approach
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 }
@samth
Copy link

samth commented Dec 12, 2012

I'm still a little confused here. Your example doesn't ever use P_IPAddress or P_Packet. Also, can you give an example of an operation that requires a deep structural check that fails?

@dherman
Copy link
Author

dherman commented Dec 12, 2012

The .cursor operation provides an iterator that yields a pointer object (the same object each iteration, in fact; it just updates the pointer to point to the next element) so there's no need to explicitly use P_* in this example. I just added those to show how the constructors would be built.

The one place where the type check must be performed is if you create a pointer and update it. The update must point it to the same type.

let p = new P_IPAddress;
p.setTarget(lotsOfPackets, 42, "addr"); // type check occurs here

@samth
Copy link

samth commented Dec 12, 2012

I guess I still don't see where the difference is. Is it just that you couldn't use Array types inside Struct types? That seems like a stronger restriction than you described in your email. Other than that, your programs are identical, and I get the sense that the loop bodies would be identical too.

Also, I'm still confused about the signature/semantics of setTarget, so your example isn't totally helpful. Does that example succeed or fail?

@dherman
Copy link
Author

dherman commented Dec 12, 2012

The StructView version can only point to struct types, as the name suggests, whereas the PointerType version can point to structs or (fixed-length) arrays.

With StructView it seems not-unreasonable for the type equality semantics to be nominal. That means a single, atomic tag check whenever doing a type check. With PointerType we could make structs nominal, but checking array types still has to be structural.

As for setTarget, the signature is variadic; it takes a binary data object and one or more property names/indices. That example succeeds, because it asks for lotsOfPackets[42].addr which is an IPAddress. If we'd written:

p.setTarget(lotsOfPackets, 42); // error

it would throw, because lotsOfPackets[42] is a Packet, not an IPAddress.

Does that help?

@dherman
Copy link
Author

dherman commented Dec 12, 2012

(Another way to look at it: we could imagine calling it PropertyView instead of StructView, 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.)

@samth
Copy link

samth commented Dec 12, 2012

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?

@dherman
Copy link
Author

dherman commented Dec 12, 2012

The issue is just that it seems stranger for different array types to be non-interchangeable than for different struct types, right?

Right.

@dherman
Copy link
Author

dherman commented Dec 12, 2012

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment