Re: cvs: php4 /ext/msession msession.c

On Saturday 22 December 2001 02:04 pm, Hartmut Holzgraefe wrote: First off, I want to apologize for my reaction to your previous changes, I did not inspect them close enough. When I merged the changes in PHP CVS it completely broke the source I was working on. I had to go back to a previous backup to regain most of the work that was lost by CVS update. I was rippin' mad. > Mark L. Woodward wrote: > > - | DO NOT ever remove backward compatibility!!!! NEVER!!!! > > | > > well, if you want to have a single codebase for an extension > that works with several versions of PHP then the PHP CVS > is probably not the right place to maintain your code in It makes no sense to have to have more than one codebase. It is a standard professional practice to "ifdef" newer versions and retain backward compatibility. > > from my understanding extensions bundled with PHP should take > advantage of internal API changes where ever possible, > as it just doesn't make sense to introduce improved mechanisms, > especially in case of things like the new parameter parser that > is meant to *improve* readability of source code, while mixing > old and new stuff in a forrest of #ifdef directives > (don't get me wrong, i'm takling about c code bc, not user level bc) I have no problem with using "new" APIs if they are better or if the old ones are obsolete. My problem is when backward compatibility is lost on working code. A skilled engineer uses macros and ifdefs to maintain backward compatibility. > > if you have changes you want to apply to pre-4.1 versions then > you should probably merge them in the release branches in CVS > separately Why is that necessary? > > for the current status of the source: if you want to stay with > the old parameter passing style then please remove the ifdefs > and the new style version completely Why? ifdefs are a normal part of C code. Should we eliminate "sprintf" because it is too complex? Should we say you can't use other constructs in C because people have trouble reading them? What about complex macros? Many engineers have trouble with macros that use the pasting operator. It is perfectly reasonable to if ifdef/else/endif brackets in code. Do you disagree? > > the main reason for the new style function is readability and > ease of use, with both old and new style encapsulated in #ifdef's > whe have reached none of these goals :(( Are the new functions any more efficient? Are the old functions going to become obsolete? If either of those statements are true, then it is perfectly reasonable to keep the new versions and the old versions. I wish this code to be backward compatible with previous versions of PHP as well, this can hardly be considered an unprofessional or unreasonable goal. > > > - | DO NOT rename my variable names > > | > > ok, this wasn't very clever (to much to soon), > but we usualy do not use those type encoding characters in front > of variable names (although there is no written rule here), and > the string handling in the new parameter parsing function made > me finally change this as having a 'int ihost_len;' besides > 'char *szhost;' didn't look readable and intuitive to me at all Intuitive is subjective. Let us not all try to rewrite everyone's code that it is intuitive to ourselves, shall we? Lets take steps to understand and respect each other's code. We all have different styles. I have been programing professionally since 1982, I have a style that works for me. With a little practice the "Hungarian" notation is VERY usefull practice. Again, I do not wish to sell you on Hungarian notation, I just wish you to keep your personal tastes to your code and I'll keep mine to my own. When I edit the code of others, I try to understand their naming, their style, and their format. I try to make any mods that I would make fit in. It is a matter of professional respect. > > > - | DO NOT reformat by braces, if you don't like the way I brace my > > code | - | too bad. I take strides to follow the format that other > > authors use | > > php4/CODING_STANDARDS, Syntax and indentation, Section 2: > > [2] Use K&R-style. Of course, we can't and don't want to > force anybody to use a style he or she is not used to, but, > at the very least, when you write code that goes into the core > of PHP or one of its standard modules, please maintain the K&R > style. This applies to just about everything, starting with > indentation and comment styles and up to function declaration > syntax. "of course we can't and don't want to" is the operative phrase. Open source is a chaotic environment. If you are intolerant of the different styles of others, you will find that people will find it more trouble than it is worth to contribute. BTW, mine is not the only extension that brackets code with the opening bracket on a new line. At least mine is consistent.