User talk:EMBee/Binary Serialization

About Binary Serialization

Hi, I did not want to pollute your Binary_Serialization page with kibitzing, but I still wanted to make a few comments. That said, my topics are intertwined and perhaps ill-formed:

1. Objects are the anti-serialization.
2. Some arrays have multiple dimensions.
3. Some integers can be large.
4. Serialization and RPC are different, though related topics.

So, first off, you cannot serialize an object. You can serialize a copy of an object, but objects are things you refer to, they are not their state. This leads to numerous complexities when people try to serialize objects (or when they confuse message passing with serialization). You could hypothetically serialize an object reference, but conceptually what you would want to do is publish an RPC interface (which raises issues like object lifetime and references, security and so on). Similarly, you can serialize object state, and descriptions of an object's interface, and these are also topics which can grow without bound and perhaps deserve an encapsulation barrier. --Rdm 15:16, 21 October 2011 (UTC)

Second off, a matrix is an array with two dimensions. Sometimes you might have reason for arrays with more than two dimensions. In the general case, an array might be a region of memory, a type, and a list of dimensions (where a list of dimensions is a degenerate array whose type is known and whose list of dimensions itself only has one dimension and that 1 element list is a further degenerate case). All of which generally makes it popular to only deal with degenerate arrays... Note though, that I have implicitly assumed that all elements of an array are the same size. If you need to deal with variable sized elements you can degenerate this to an array of references to elements, or you could degenerate it to something else (like the linked list where you have a degenerate array containing two references, the second of which is a reference to the rest of the linked list). You can also degenerate the concept of a reference and have variable sized elements and force the reader to walk through each element to find the nth element.

Arbitrary precision integer implementations share concepts with arrays or degenerate arrays (they wind up being variable sized).

Getting back to objects, the whole concept of RPC can be interesting and useful, but it's probably best to implement as a separate layer from serialization. Meanwhile, your current draft has a "transaction id" which I think does not belong in serialization but could belong in RPC.

Anyways, this is something to think about? For the context of your draft page, I do not know if I am suggesting a change in title or a change in implementation. --Rdm 15:16, 21 October 2011 (UTC)