On Tue, Jan 20, 2009 at 12:10:56AM +0100, ml wrote: > here are some proposals for the code: > - reduce $GLOBALS (e.g. $t in forms.php)
I very much agree with this one. > - drop PHP4 support (outdated) I don't see dropping PHP4 support as a goal on its own. If there is something that we want to add to PmWiki and where PHP4 support is holding us back, then we can consider it. But there are still a lot of sites (including pmwiki.org) that are using PHP4 and I don't see any purpose in dropping PHP4 support for its own sake. > - move confiiguration items to a separate class ($GroupPattern, $NamePattern, > etc. => class members), no more "global $StopWatch" I don't know that we'll eliminate global variables entirely. If I had things to do over again, I would put all configuration variables into a $Config array and provide some functions to easily set defaults and obtain values from that array. This would also make a "control-panel" type interface easier. The problem with simply switching to such a structure now is that it might break a ton of sites and recipes, so we really need a smooth migration plan. Hopefully one that doesn't involve a long "beta" series. > - reduce unusual abbreviations (PSS, PVS, PVSE, PZZ, etc.) > and/or add PHPdocs to help Zend/PDT users reading the code The unusual abbreviations are there for a reason -- without them portions of the code become very very long and unreadable (to me). I have no problem with documenting these functions very well, but I prefer to keep the abbreviations. Stated differently: Most communication forums and (written) languages have abbreviations in them for a reason -- they serve to simplify communication among people working within those arenas. Yes, it sometimes means that newcomers to the system have to become familiar with the abbreviations, but that doesn't mean that we should throw them out entirely. > - make UTF8 the default encoding This is the one I'd be most eager to see us tackle, but also one of the most difficult. It's not a problem for new installations of PmWiki, but it's very difficult to provide a way for existing sites to convert over to UTF8. I've already put some internal items in place to help with this -- for example, each page file includes a field that indicates the page encoding used to save the page. We could use this to convert page text on the fly. More difficult is dealing with page filenames -- we would want some way of either (1) converting all pages on a site to UTF8, or (2) automatically probing for all filename types that could exist. Actually, now that I think about it, I might have a good way to do #1, so perhaps we can work on this soon. Pm _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
