From: Hollosi A. <aho...@xm...> - 2001-02-23 11:34:40
|
Hi all, Reading responses from Jeff, Steve and others I'd like to clarify my point: my main issue is not necessarily about adding too much new functionality. I for one would like to see things such as version history included as well. Also, I'm no big fan of making templates too fancy, but if it is well designed, so be it. My main point is "ease of use" (mentioned by Steve): > admins: PhpWiki should be easy to set up and administor. > hackers: PhpWiki should be easy to understand and modify. > users: PhpWiki should be easy to use for writing hypertext. If we keep this goal in mind, then it should be no suprise that adding new features has to be done with care. I think that one main reason why open source is (still) working if the project grows larger is modularity. I.e. a program should have a modular design and people should be responsible for different modules. This requires that we think about design *before* we implement stuff. phpwiki is not algorithmically challenging - coding is easy. Making good design is a challenge. Furthermore, it should be easy for new hackers (or for ourselves) to grasp the big picture of phpwiki. That means that we should have a clear design with __very few__ core data structures or objects. Currently these core objects are $dbi, $pagehash, and WikiTransform. Wether they are written as real objects or as data+functions is just a matter of taste -- I don't object making them real objects. My statements about phpwiki getting too fancy are mostly related to coding style - not necessarily to functionality. A good example is include_path vs. $phpwikiroot. Also, I think we should pay more attention to commenting the code. Comments about functions, plus maybe a comment at the top of the file giving the big picture of what's happening should make it easy for people to find their way around. To that extend I suggest that noone checks in stuff unless it is commented. For example, I saw that Jeff(?) changed the way tokenizer functions work. Yet, the comments were not changed to that effect. Keeping comments upto date is easy if you check/modify comments every time you make code changes. If way wait for the big cleanup session before a release then updating comments is a royal pain ITA. Exactly how much comments are needed should be discussed in our coding guidelines. /Arno P.S: I just thought of a nice comparison: coding and Jazz (or music in general). Imagine a Jazz quartett of geniuses (pick your personal favourites). Everyone is a wizard, everyine can play elaborate, highly sophisticated melodies, or show off their mastery of the instrument. Yet, most of the time they hold back and play apparently "simple" stuff. Only when it's their turn for a solo, they really show what they are capable of. Take coding: if you are a real master then strive for writing elegant simple code which everyone (even mere mortals) can grasp easily. This is the real challenge. |