skids/packish

## packish

So, after saying yesterday on IRC that a bottom-up design shoud come first for packish things
I somehow came over with a case of hypocrisy and thought a bit about top-downish stuff.

Suppose we had a role-like MOP construct (bikeshedding welcome on names):

packing foo {
    template bar {
        # pack template bottom level constructs
        # templates can nest, and can come from mixing other packings
    }
}

This could be mixed into classes and into grammars.

When mixed into a normal class each template would create normal non-packed attributes which the
class could then serialize to a buf.  This would be needed when we want to mutate non-fixed size
things.  It would use the template to choose appropriate types/subsets/constraints.  A default
automatically generated serialization method to produce a buf would be available, and could
be overridden/wrapped.

When mixed into a CStruct class each template would create accessors to emulate attributes
from an underlying buf initializer.  This type of class would store in serialized format and
only allow mutations that do not necessitate a resize (eventually maybe we could allow shrinking,
or adding some padding ahead of time for growing.)  It would require a variably-sized
CStruct REPR, or maybe we need a different REPR for that, depending on the internals involved,
adjust the first sentence of this paragraph accordingly.  Importantly it would be possible
to get an unmanaged memory object to serve as the storage in case we are mapping a hardware
device MMIO or buffer.

When mixed into a grammar each template would create a rule that can match a binary structure.
There would also be some kind of convenient way to cause that rule to make objects of a
corresponding class.

This "role" like construct would actually be a bit more MRO than roles, in that there would be a way
to prevent rules and attributes from certain roles from being visible, so if you do not want
the templates from all sub-packings appearing in your class/grammar you could prune them easily
(and thus we need to keep a heirarchy not a flat role list.)  This fleibility actually an important thing
especially for network formats where simple heirarchy breaks down due to the fact that the encapsulation
around a packet does not really fit the "parent" model nicely and you want to be able to treat
things received with different encapsulations the same.

Oh, also, might want to start keeping a list of various gists people have published on related topics.
Let me know if there are others out there.

https://gist.github.com/ShimmerFairy/72a25f87939aab077158
https://gist.github.com/Juerd/ae574b87d40a66649692
https://gist.github.com/smls/bc5d0fb42f199574e339
https://gist.github.com/masak/1239203
https://gist.github.com/skids/4998260 # very old, low level types thoughts

Also related is jnthn's talk on Grammar::Generative

https://www.youtube.com/watch?v=RPQvtfwsilM

	So, after saying yesterday on IRC that a bottom-up design shoud come first for packish things
	I somehow came over with a case of hypocrisy and thought a bit about top-downish stuff.

	Suppose we had a role-like MOP construct (bikeshedding welcome on names):

	packing foo {
	template bar {
	# pack template bottom level constructs
	# templates can nest, and can come from mixing other packings
	}
	}

	This could be mixed into classes and into grammars.

	When mixed into a normal class each template would create normal non-packed attributes which the
	class could then serialize to a buf. This would be needed when we want to mutate non-fixed size
	things. It would use the template to choose appropriate types/subsets/constraints. A default
	automatically generated serialization method to produce a buf would be available, and could
	be overridden/wrapped.

	When mixed into a CStruct class each template would create accessors to emulate attributes
	from an underlying buf initializer. This type of class would store in serialized format and
	only allow mutations that do not necessitate a resize (eventually maybe we could allow shrinking,
	or adding some padding ahead of time for growing.) It would require a variably-sized
	CStruct REPR, or maybe we need a different REPR for that, depending on the internals involved,
	adjust the first sentence of this paragraph accordingly. Importantly it would be possible
	to get an unmanaged memory object to serve as the storage in case we are mapping a hardware
	device MMIO or buffer.

	When mixed into a grammar each template would create a rule that can match a binary structure.
	There would also be some kind of convenient way to cause that rule to make objects of a
	corresponding class.

	This "role" like construct would actually be a bit more MRO than roles, in that there would be a way
	to prevent rules and attributes from certain roles from being visible, so if you do not want
	the templates from all sub-packings appearing in your class/grammar you could prune them easily
	(and thus we need to keep a heirarchy not a flat role list.) This fleibility actually an important thing
	especially for network formats where simple heirarchy breaks down due to the fact that the encapsulation
	around a packet does not really fit the "parent" model nicely and you want to be able to treat
	things received with different encapsulations the same.

	Oh, also, might want to start keeping a list of various gists people have published on related topics.
	Let me know if there are others out there.

	https://gist.github.com/ShimmerFairy/72a25f87939aab077158
	https://gist.github.com/Juerd/ae574b87d40a66649692
	https://gist.github.com/smls/bc5d0fb42f199574e339
	https://gist.github.com/masak/1239203
	https://gist.github.com/skids/4998260 # very old, low level types thoughts

	Also related is jnthn's talk on Grammar::Generative

	https://www.youtube.com/watch?v=RPQvtfwsilM