debunking the myth that Greg doesn't like classes :)

Hi all, Just for the record, I am not against using tons of classes. The refactoring I have been doing in PEAR is exactly that: split behemoth things up into more classes. This is in addition to work done adding features of course. What I have not done is add a class for every single data element. Some data is better represented by native PHP types in PHP. I have learned this the hard way through MANY years of programming. Case in point: the original version of Games_Chess had a class for each square on the chessboard, and classes for each piece on the board, as well as a blank space. After it turned out that I had designed some limitations into the rules for the game in the design of the pieces, I began refactoring the classes. Shortly thereafter, it became apparent that several thousand lines were devoted to working around the complexity that came from what was essentially trying to do matrix algebra with classes and delegation as well as cross-referencing classes (square class with piece class). In addition, I couldn't get it to work, and looking at the code couldn't even understand where to begin debugging. So, I erased every file and started from scratch. What I had missed the first time around was that each piece/square was not an object even though they appeared to be because they are in real life. The only true object was the chessboard itself. The squares were simply containers for pieces, and could be more easily represented using an array. Each piece only possessed 2 qualities: name and color. In addition, pieces can change identity (pawns can become queens/rooks/knights/bishops). Once I recognized that pieces were simply data, it became a simple task to implement the chess engine. All I needed was some basic move calculation methods and a few backend classes to implement the rules of interaction between the pieces for different flavors of chess and I was rolling. Not only does the class work better, but I saved on the most important benchmark of all: developer time. The more unnecessarily complex a solution is, the harder it is to debug or add features. I don't claim to be immune from adding too much complexity in my own code. There are more than a few developers here who can attest to that. I have had my fair share of ideas I have fought for that later turned out to be overly complex. My problem has never been oversimplifying. As for XML_RPC2, I am sure my dogmatism and Sergio's dogmatism could work together for a better class than either one of us would implement on our own. I've been known to compromise a few times in the past, but don't tell anyone. Greg