[PEAK] Circular class adapters..

[Phillip J. Eby]

At 10:31 PM 2/19/04 -0500, Bob Ippolito wrote:
>If you want to take a look at what I am using circular class adaption for, 
>I have made a snapshot of ptypes at 
>http://undefined.org/python/ptypes-20040219.tgz -- you will need to 
>install a VERY RECENT (as in hours ago) CVS version of PyProtocols if you 
>want to play with it.
>
>It's basically a toolkit for reading/writing binary formats with an API 
>sort of like ctypes.  It includes support for an "iterfunc" reading style 
>(generator abuse), so it can be hooked into Twisted and read off the wire 
>incrementally without needing Stackless.  The goal is to be able to define 
>these data structures in such a way that it does as much of the 
>boilerplate reading and writing as possible.

Interesting.  I'm curious about something, though.  You use BaseObjectsList 
as a base for a lot of things, but it looks to me as though it'd be simpler 
to just create an adapter from a sequenceOf(IFunctionWritable) -> 
IFunctionWritable, and from a sequenceOf(IOutputSize) -> IOutputSize, and 
so on for any other capabilities that need to be done across a sequence of 
items.  Then, you could just use sequences of "types" directly.

There seem to be other things that also seem one level removed, like the 
various 'str' subclasses.  But maybe I'm not following the actual use cases 
of the library correctly.

It would seem to me that I would define a format as a protocol -- possibly 
parameterized -- and then use adaptation to define writers directly.  For 
example, instead of having 'pypackable' create a class, I'd make it a 
Protocol subclass with parameters, that automatically registered 
appropriate adapter function(s) for builtin types, or maybe from an 
IInteger, IString, etc.  And the new protocol object would imply a base 
protocol for writing or reading.

I think this approach, or something like it, could remove one level of 
"meta" ness throughout the library, making the code simpler and easier to 
follow, while possibly expanding the flexibility further.  But, I've only 
made a very brief pass over the code, so I could be missing your critical 
use cases.