[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

Reply via email to