On Fri, Feb 08, 2002 at 11:43:07AM -0700, Chris Fedde wrote: > On Fri, 8 Feb 2002 17:56:35 +0100 [EMAIL PROTECTED] wrote: > +------------------ > | > in lieu of consensus, i'm probably just going to play with some stuff on > | > my own. you guys will probably hate it but oh well :) > | > | you need to think about it first and find out how to do it. no code needed > | for that. maybe you just try finding the really tricky problems before you > | start coding. it needs practice and there are several techniques etc. meant > | to help people with that (for example UML models, objects life cycles, ...). > | It might be no fun in the beginning, but it enables you to work on bigger > | projects. And to actually succeed. > +------------------ > > I'm of the opinion that UML is yet another good idea that has been > elevated to the status of Golden Hammer. I've been in groups where > full analysis approaches have lead to way too much navel gazing, > missed deadlines, and lots of finger pointing. Plus such approaches > do not fair well in the open source community because of the lack of > central authority.
I've noticed that as well. But I do think that this is mostly because people don't know what they're doing. Like everyone wanting a portal or peer to peer just because everyone talks about it. A lot of people don't even know about it or just heard the name. All that ends in chaos and unneeded words if you do not know how to do it right. And there is no tool support for perl. The pros are that it is a formal and standardized way of describing things. You don't need a central management or project control for it (modularity). It is in use and not just the buzzword, although often people only know the word. But _if_ we want to build something big, we can't just code and see where the code gets us. > > I've come to be a fan of the XP approach and it's reliance on > customer stories, a spike implementation, automated testing and > refactoring. This closely follows the typical life cycle of most > open source development. And it works well with Perl. XP has the analysis -> design -> implementation -> testing life cycle as well, but the problem is divided and weighted differently. But if you take a look at the way cost/gains are calculated there you will see that it doesnt make sense to divide closely related subproblems. Unfortunately at lot of people think that XP means just hacking. > > So my question is this: Are there projects along the way to an > object layer that can be implemented and be useful by them selves > without needing the whole infrastructure? Well how high should we aim ? I numerated some potential features in one of the last mails. We should first reach consensus what we need most (to follow XP :). Dependencies need some work afterwards. I personally know what I would like to have. But I don't really know what you, Matt or Rocco want, for example. Trying out something that we could code right now doesnt make sense. Possible sub problems that could be easily isolated (and are related to the object layer) are: -named parameters -IO streams (getting away from the wheel stuff) -session enhancements (making them more similar to real OOP) stuff that is not suitable would be: -anything related or influenced by the concurrency model (headache stuff), depends on too many non-POE things to decide right now -anything that we/you/me do not know enough about (especially the people that think discovering the tricky parts during coding is a normal thing) there are more items for both categories. Matt said there would have been discussions about the object layer for a whole year. I dont think this is true, at least they were just POE not object layer. But in the whole time Rocco and me were not able to agree on wether state transitions in POE::NFA should be part of the event handler or asynchronous. This is a very bad sign (but I don't like forks). Have you looked at all the other projects trying to do object layer like functionality? Pieces thrown together, but nothing new there, or at least beautiful solutions. I (we?) do not need to earn money with it, so I'd dislike creating something not coming close to the right thing. Torvald
