note adrianh <blockquote>Are there instances where OO perl is the only choice?</blockquote> Not really. You can always write a piece of procedural code that will do the same thing as a piece of OO code. However, there are many times when OO is a sensible choice. For example if you've got an existing OO system that needs extending, or an OO framework that matches your application. Personally I find an OO approach makes most non-trivial applications simpler to develop - but this edges onto religious argument territory. You may find [id://91080] of interest. <blockquote>Say you've written a pretty large program written mostly in proceduaral perl. Can you easily re-write that program in OO perl later if you choose to?</blockquote> Depends. Often not. Procedural code often tends to separate data and the processes applied to that data. OO tends to do the opposite. It is possible of course, but may be non-trivial. <blockquote>Does anybody have any idea how perl 6's implementation of OO perl is going to be like? If so, is it going to be differnt from the current implementation? </blockquote> Yes it will be different. We won't know the details until the next Apocalypse comes out. Reading the other Apocalypses gives some hints. At the very least we will see: <ul> <li>Classes as first class objects</li> <li>Multi-methods</li> <li>Decent encapsulation of attributes and code</li> </ul> Probably a lot more. As I understand it the old Perl 5 style object system will still be usable, but the newer structures offer considerably more flexibility. 291379 291379