On Fri, Feb 08, 2002 at 05:56:35PM +0100, [EMAIL PROTECTED] wrote: > On Fri, Feb 08, 2002 at 10:50:25AM -0500, Matt Cashner wrote: > > On (02/08/02 16:38), [EMAIL PROTECTED] wrote:
[etc.] Man, this is SO far off topic. Get a room, or at least a new Subject. == Sorry, no perfection. == As you may have noticed, POE is not yet complete. Still, people have been doing wonderful and terrible things with it for over three years. A lot of the improvements during those years have come from people getting into POE, doing things with it, and finding problems that I had never foreseen. That kind of developer/user interaction is too valuable to give up, and I won't consider a plan for POE's future development that requires us to. == Incremental design. == I think an object system can be built in pieces. Most of the pieces will work right away, giving developers some instant gratification. We'll also get early and often feedback from people using the pieces, and that can be folded back into our designs while things are still pliable. POE::Component is the first piece. It's not built yet, but its design has been implied by the components built within its namespace. Here are my recommendations for the next few pieces. They seem to implement the largest portion of needed features, and they'll enable a lot more wonderful (and yes, terrible) things to come. You'll notice that all of them have been suggested to me in the past. I apologize taking so long to understand their importance. == Messaging. == Torvald, I think, suggested that an inter-component messaging system would be a good start, and I've come to agree with that. The existing components would benefit from a simpler way to pass messages. IKC can be added in later as a behind-the-scenes message router. Messaging can start as simply as named parameters and message objects. I've already written a prototype of a Session that accepts message objects rather than fields in @_. With just a little forethought, it should be incrementally extensible into a full-blown polymorphic [insert favorite feature here] message object taxonomy system thingy. I do not expect it to be perfect from the outset, but we could get lucky. Matt Cashner is working on a prototype messaging system as part of a larger project. I'm looking forward to that. == Inheritance and aggregation. == We'll have no end of trouble doing practical things in an object system that doesn't cleanly support ways to combine objects. I've begun compiling a list of pattern inheritance and combining patterns as I come across them. Hopefully some clean patterns will emerge from those notes. It's slow work, and it could use input from more people. == Threads. == Threads are listed last because they are the most important, least visible, and hardest to do correctly. Threads will let sessions block without adversely affecting other sessions. That will open a lot of CPAN to POE users, which is a very nice thing. Combined with messaging, it will let POE act as a form of RPC for other modules. That's good, too. Artur Bergman is working on a "dream design" (I hope) for threaded POE. We'll hash out how close POE's current design can approach his fondest wishes without breaking. Mission statement. Mission statements suck, but it occurred to me that we might need something to focus on. I know I do. Do I EVER. How does this sound? Create a coherent, extensible framework for object interaction. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
