At 00:55 18/07/2007, Pierre wrote:
My answer to Andi was not only about ereg but php6 in general (the
unicode flag being a much more important problem that ereg, for
example).
I fully agree with you. Each individual here does not represent the
user base but only a relative small part.
However, my problem here is not about that but about the respect of
our voices. It is understandable that you think to have a brighter
customers base, it is not necessary the case. not historically and not
practically. Conferences attendees are also a very small part of our
users.
All in all, internals developers, with their customers, coworkers or
users (Ez, PEAR, linux package maintainers, etc.) do represent what I
consider as a good representation of what our users are or like to
have.
I think that they're still quite far away from a real coverage of the
entire userbase. Each of them sees a certain part of the userbase
through a different prism. I think that some of us get to see people
through some more prisms than others, and you may very well be one of
them - but they are still prisms, and I *think* that most of us don't
get to meet some of the lower 'average' developers. The ones that
don't respond to blogs, go to conferences, let alone participate in
[EMAIL PROTECTED] The ones who constitute the vast majority of PHP
developers around the world - those using it to get their job done.
If you noticed, I didn't just speak about the users that I meet, but
trying to put myself in the average user's place using a simple
thought experiment. I think using this approach (the famous 'WTF
factor' is a part of that) helped PHP tremendously and was one of the
key reasons for its success.
That's why I'm pretty confident you'd get a very different (much more
balanced) view of the world if you ask the question in a more neutral
environment - such as php-general (and even that list arguably
includes people with above-average interest in PHP - given that we're
talking about millions of developers and only thousands of
subscribers). Can I realize, from an end-user's point of view, why
the removal of a certain feature that I'm using would help me? Or
will it be much easier for me to imagine the pain involved with
working around it?
Other than the theological views some people on this list have
(either very pro-BC or anti-BC), what did keeping BC cost us?
About the migration path, we should not forget our PHP5 lessons. All
Andi is trying to do was what was done with PHP5. Many cleanups have
not been done for the sake of BC breaks and migration troubles. We
know now that it does not matter. Users migrate when they have to or
need to not just for the fun of it.
I think we're learning very different lessons from the same facts.
PHP 5 migration stalled because of several reasons, the key of which
are (IMHO):
1. Misperception about the level of compatibility breakage.
2. Correct perception that moving to PHP 5 requires a full QA cycle
of your entire codebase with full code coverage (assuming you're
running a critical app that you can't afford to break, which needless
to say thousands and thousands of users do); And contrary to popular
belief, that's actually a very very big deal.
In the shared hosting arena there's supposedly also lack of support
for PHP 5 deployment, although the big hosters I've been in touch
with have provided PHP 5 support (as an option) a couple of months
after its release, so I'm not sure how much this had to do with it.
Is the lesson we should learn that we need to turn #1 into a correct
perception, requiring substantial changes and potentially a full code
audit, and make the migration much more difficult? Would we ever be
able to discontinue PHP 5 if migrating to PHP 6 is a truly tough
task, like we just did with PHP 4?
The less undue compatibility breakage we introduce the better. I
hope we can agree on that - turning the discussion into what's
exactly 'due' and what is 'undue'.
IMHO - if we remove the unicode=off mode, we'll have to support PHP 5
(unlike we supported PHP 4 with bugfixes only for the most part - but
with true backporting of all key features, apps & frameworks running
properly on both versions, etc.) or seriously risk losing our
userbase. Given that we managed to nail it fairly well already, I
can't understand why we would want to do that and increase the
chances of PHP 6 being a flop quite significantly.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
