Mark Overmeer writes: > * Jonathan Scott Duff ([EMAIL PROTECTED]) [070616 20:15]: > > > You mention OOP. For Perl 5 we have a standard, if very general, > > syntax and "open" semantics that have allowed people to implement > > OOP in a variety of ways. This was all well and good for a while > > until we realized that there should be some more reasonable defaults > > (in both syntax and semantics) for common operations in OOP. > > OOP in Perl5 has a mechanism, but not a standard in the use of those > features. Full OO languages all choose a direction, but there are > serious culture differences. Perl uses them all. There are many ways > how to instantiate an object, which is lot of fun as programmer but a > hassle for "the average" programmer. Within one program, you may very > well need to use different instantiation techniques... Of course, > this could have been forseen (perl is not the first language which > implements OO), and some advice on the convention to use could have > avoided wild collection of approaches we see now.
But if this had been "forseen" and restrictions put in place, then we wouldn't have had the recent advances in things like inside-out objects and MOP. The flexibility and people doing different things allowed for experimentation, and where those experiments were successful new ideas gained community mindshare very quickly. > This is also why "Perl Best Practices" is a good book [shameless plug] Indeed. But it doesn't need to be part of the Perl core. > although I would have welcomed it 11 years earlier. But it extols many practices which weren't thought of 11 years previously! Hence the need for flexibility, so as to allow time to invent them ... > > I think it's the same thing with POD6. It's "open" enough that many > > documentation systems can be built from it (man pages, books, > > magazines, wikis, etc.) For some of those documentation systems > > we'll have nice conventions and other conventions will grow as > > needed. If we find that convention isn't enough in specific areas, > > ... > > Without any doubt, there are thousands of documentation systems > around. At least ten percent of them are considered "the best ever > made" by its developer or developer community. Just by simple math, > the chance that the system developed really is the best is less than > one percent. Quite so -- which is why in my previous mail I thought it was shortsighted to think we can create something now which we won't later want to change. > IMO, any argument that POD6 is good because it can be used to write > books or express complex mathematical expressions is really frightning > me. POD (as in the version with Perl 5) wasnt designed for writing books or whatever, yet people liked it enough they took it in directions that nobody first expected. There's a good chance of that happening with Pod 6, even if it isn't an aim. > Every single complication added to the doc syntax will make it not to > understand for a large percentage of the primar target community, as > every teacher can tell you from experience. You could say the same thing about Perl 6 (or even earlier versions), yet we cope, partly by ensuring that you don't need to learn all of it in order to be able to use it. (In the case of Pod one of the things that helps is its large overlap with plain text.) > When I create a program, it starts with a goal. To reach that goal, I > have to write some code, some docs, some tests. For me, it is all > part of the program. I do not see one to be of more importance than > the other: all three are first-class sitizens in my program. Testing is another area which has had immense progress since the release of Perl 5. Look at where Test::More, Test::Class, TAP::Parser and so on are now; we certainly wouldn't want to be restricted to a standard of best practices in testing from the early 1990s. Smylers
