> [EMAIL PROTECTED] wrote: >> 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
I wrapped the new parameter stuff in the #ifdef/#else/#endif because someone had put some work into it. I did not wish to remove someone else's effort. > > 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 Thanks. > > 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 What did I revert? What did I remove? If any functionality was removed, it was an error on my part. I had some local changes that I wanted to check in, and I needed 4.0.x compatibility so I could use it on my site. > >sure, backwards compatibility is a "nice to have", but it's not our >primary goal as far as extension source code is concerned This sort of bothers me. Who is this "our" you talk about? As contributor of the msession extension, am I not also part of "our" and don't I get a say on the priorities of msession? >> 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 If I were doing something complicated, I would be careful about obfuscating the code. IMHO the msession extension is an nothing more than interface layer, it is meant to handle these issues. > > 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 I can understand your position, but the msession extension not a difficult peice of code. I have updated the proto comments so they correctly state what the functions do. Just tell me what else you want for comments. > 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) I would be glad too. I have a PDF white paper on my website. I can rewrite it into a different format if you like. It is authored in StarOffice. >> 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 I am dubious of CVS merging. I have spent my time fixing CVS merge errors, thank you very much. > > 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? AFAIK msession is not in 4.0.6, but for people who can't upgrade to 4.1, I can tell them to get it from PHP CVS. > > >> 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) Why is it such a problem? Why are we wasting so much time on this? This makes no sense to me. I think you guys are a bit out of control. Chill out. -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
