On Thu, 2004-02-26 at 19:47, Phillip J. Eby wrote:
Yeah, my problem is that I don't usually write stuff to solve simple problems, because if it was a simple problem, somebody else would probably have already written something to solve it, and I could just download their implementation and be done with it. :)
So, when I write something I'm almost invariably thinking about *hard* problems, and that tends to carry over into my documentation.
I can understand that inclination myself, having more than once heard Twisted accused of being "an impressive solution for which there are no problems". However, PEAK's documentation has been dense even for me. I certainly could not accuse if of not being thorough :). In a discussion with another Twisted developer, it struck me that we may be coming at the problem of components from completely different angles. I didn't understand why components were interesting at all until I started to play with using them in the context of separation of concerns within simulations. Since these concerns can become independently quite large, manage independent state, and are largely interrelated only at relatively few boundary points, they're well-suited towards collections of stateful adapters. Compared to the use-cases I've attempted to satisfy there, every usage of adapters has seemed trivial. Looking at PyProtocols, it doesn't seem to me to have taken simulations or gaming into account as a use-case. An indication of this is the seperability of the full component model from the interface / adapters system. Without a full understanding of the execution context of an adapter, I don't know how I could integrate external adapters like TTW login or email delivery into a simulation. (Pardon me for not being terribly specific here. It's difficult for me to come up with examples that take less than 5 or 6 pages of dull prose to explain.) However, I am not sure, because I can't figure out what PEAK as a whole is really for. The likely source of an explanation, http://peak.telecommunity.com/Articles/WhatisPEAK.html seems awfully vague. What is the problem that PEAK was designed to solve, exactly? Clearly it was difficult, because there was a lot of solution :) An aside, for any would-be component system or documentation authors in the audience: much general literature on the use of components - including the Twisted component tutorial, I might add - is maddeningly vague, somewhat like "object oriented programming" tutorials. I don't need to simulate simplistic bicycles or shapes or electrically incapacitated hairdryers, I want to write networked applications and video games, and it's not clear which concerns I should separate, how, and when. Why does this stuff help me?