[EMAIL PROTECTED] wrote: >>[EMAIL PROTECTED] wrote: >> >>>Removing backward compatibility for aesthetic reasons is bogus. To be >>>perfectly honest, I think the whole PHP extension API is truly ugly. >>>The removal of a few #ifdefs will not a Mona Lisa make. >>> >>to me "readability" is a maintainance issue, not an aestheic one ... >> > > Perhaps for you it is, but not everyone agrees with you. Open source is > about freedom, is it not? > > >>if you don't care about others to understand your code, or even don't >>want anyone to touch it anyway (as you already have made clear), >> > > I have made no such declaration. I just do not think well placed #ifdefs > affect readability or maintainability. That is your opinion, not mine. I > welcome anyone to add features to the msession code as they see fit. All I > ask is that they do not remove backward compatibility. This is not an > earth shattering request.
we had several points in our last argument, and BC and #ifdef's was only one of it. for that one i had suggested to revert to the old parameter parsing style (which still works and *is* BC on the source level) instead of having it both ways, wrapped up in #ifdef OLD_ZEND_PARAM as the *only* reason for introducing the new parameter parser was readability and maintainability in the first place, while in this case you'd reached the complete opposite just for the records: it was me who put in the final missing piece to make it all 4.0.6 compatible again in rev. 1.15 of msession.c and this time you've hit a nerve by reverting a patch needed for current dev version in favour of 4.0.6 compatibility AFAIK sure, backwards compatibility is a "nice to have", but it's not our primary goal as far as extension source code is concerned > I am really tired of this argument. Why do you care? Why does anyone care? > The code is fairly readable, it doesn't do anything hard to understand. It > is a simple thunk/trasport layer for another library all together. If > anyone has trouble reading or understanding it, I would suggest that they > need to take a basic C class. even for a coder it is not always easy to adopt his mind to different coding styles in otherwise similar pieces of code and to untangle nested conditionals but we do not only have coders on this project, but also people doing the documentation that might not be so fluent in C or might not even code C at all thats what we have the "proto" comments for, and the new parameter parser API was ment to make it easier to verify that a given proto comment matches the actual paramter evaluation, besides other issues > More over, I think msession, while still a bit experimental, is a > worthwhile addition to PHP. I already have a few people using it and it > has helped them deploy their web farm. People are using it, and in doing > so people are using PHP for big things. As I understand it, this is what > we all want, right? it would be even more usefull if people knew it was there and how to use it (ooops, i'm slightly shifting to a different topic) that's why i added the proto comments (which i then used to generate the skeleton xml documentation file currently in the manual), which lead me to the other changes back then ... nothing would have happend to your code if it had been compliant with the guidlins layed down in README.CVS-RULES and other places (at least from my side) if you had followed at least the proto-comment recommendation > I think very highly of PHP. It is a great project. I submited my extension > to add value to the project. I think it can add value and help moderately > large installations. > All I am asking is that, as one developer, that backward compatibiliy > remains so I do not have to maintain two branches and duplicate work. My > time is valuable, why should I waste it? as long as a CVS release branch is 'active', changes you want to have in that release branch would have to be applied there anyway if we ever decide to have a 4.0.6pl# or 4.0.7 maintainance release for whatever reason, you would find the extension bundled with that release lacking all the features you added to the main dev branch now, no matter how much effort you'd put into keeping the dev branch BC so why not applying your patches to both branches in the first place? > This is not a lot to ask and I simply do not understand what the problem is. > In any professional environment, this would be a no-brainer. > You do not remove backward compatibility if you do not need to do so. but on the other hand there is no reason to have BC in mind on the source level if you have already dealt with that issue on another level (here: version control system) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
