Hello,
Well, I've been reading internals for years and never replied. But I think
this time I have to share my thoughts.
First of all I understand Rasmus and Stas position on holding PHP as simple
as it is. It's great and in the same way it's wrong. As Anthony mentioned
PHP evolves, and PHP is being used not only by designers who want to create
a simple corp site which by the way move to Rails, but mostly by thousands
of web agencies, developers and senior developers who constantly using
different languages and technologies. We have Ruby with all the sugar it
gives, we have Java with all enterprise mess it has. And we have PHP.
I don't think I need to advocate OOP here, and I agree with Rasmus that we
need to stay simple. But we don't need to copy all those things from Java
for example, even Java world has Play! Framework which is great and gives
simpleness to the developer. We all know how annotations are being used by
Symfony or Doctrine and I don't think we need to create all the mess it has
in Java world. We all know the problems it give, why not to eliminate it
and create a new, PHP's vision of things. Right now all discussions are
being held like we will never implement annotations because we need to copy
it from Enterprise Java. But we don't need Java annotations, we need our
own. Constantly decline great futures just because some designer wouldn't
understand it is wrong by all means.
PHP is great for web development, let's stick to it. Give us a chance to
create frameworks, which can use Annotations, DI, IoC, Factories,
Decorators and all others patterns to allow regular designer to create a
simple site with few lines of code.
--
Kind Regards,
Ignat Tuganov
Chief Information Officer
Office Phone: +7 (812) 640-8022
E-Mail \ Gtalk: it@cloudmill.ru
CloudMill LLC
191015, 3 K Furazhnyi Lane, office #317, Saint-Petersburg, Russia
PHP is great for web development, let's stick to it. Give us a chance to
create frameworks, which can use Annotations, DI, IoC, Factories,
Decorators and all others patterns to allow regular designer to create a
simple site with few lines of code.
That's exactly what annotations are for. Avoid writing the same code
over and over, define behavior using annotation.
I strongly suggest to anyone following the (too many) threads about
annotations to try the C# annotation and see what it allows. It goes
really far and greatly simplify developments and implementations of
web services (by all meaning of this word). And I very strongly
recommend it to anyone who never used or tried annotation, it will
help us to move further and move out of the current rhetoric (both
sides).
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
I strongly suggest to anyone following the (too many) threads about
annotations to try the C# annotation and see what it allows. It goes
As far as I can see, C# annotations rely on two very important things:
- Compiler support. Compiler really knows a lot about what annotations do.
- Extensive library support. Annotations themselves are just passive
metadata, what makes them work is .net framework that uses them.
This means to make annotations as useful in PHP we would have to have
substantial support in the engine (including bytecode caching
provisions, etc.) and some libraries that require very
latest-and-greatest version of PHP.
Another thing is that we're not having some features that are used
extensively in C# annotations, main being named parameters support.
I am saying this not to oppose the idea of annotations or the idea of
looking into C# and other languages (actually, I think anybody who talks
about it should look at least into what C# and Java do with it - and
also what Python does, which is completely different direction, just to
know other options). I'm just saying porting this to PHP may be less
than straightforward.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas,
I totally agree and Pierrick and I faced all these problems during the
creation of patch.
If PHP doesn't all have support required for a given feature, let's just
not only discuss feature, but also the required support too. Named
parameters is a great example. I'd also name another one,
ReflectionNamespace; namespaces are converted to strings and attached to
their classes during compile time and you can never reflect over them to
grab for example their names.
I even mentioned to Andi back in 2010 that ZE gets re-written every 5
years. That happened in 2000, 2005 and we're now hitting walls because of
"monster" changes required to implement feature A or B. Maybe it's time to
consider a rewrite again?
Cheers,
On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
I strongly suggest to anyone following the (too many) threads about
annotations to try the C# annotation and see what it allows. It goesAs far as I can see, C# annotations rely on two very important things:
- Compiler support. Compiler really knows a lot about what annotations do.
- Extensive library support. Annotations themselves are just passive
metadata, what makes them work is .net framework that uses them.This means to make annotations as useful in PHP we would have to have
substantial support in the engine (including bytecode caching
provisions, etc.) and some libraries that require very
latest-and-greatest version of PHP.Another thing is that we're not having some features that are used
extensively in C# annotations, main being named parameters support.I am saying this not to oppose the idea of annotations or the idea of
looking into C# and other languages (actually, I think anybody who talks
about it should look at least into what C# and Java do with it - and
also what Python does, which is completely different direction, just to
know other options). I'm just saying porting this to PHP may be less
than straightforward.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Oooh, a rewrite? Can we write it in an object oriented language this
time? Please? Pretty Please???
:D
Stas,
I totally agree and Pierrick and I faced all these problems during the
creation of patch.
If PHP doesn't all have support required for a given feature, let's just
not only discuss feature, but also the required support too. Named
parameters is a great example. I'd also name another one,
ReflectionNamespace; namespaces are converted to strings and attached to
their classes during compile time and you can never reflect over them to
grab for example their names.
I even mentioned to Andi back in 2010 that ZE gets re-written every 5
years. That happened in 2000, 2005 and we're now hitting walls because of
"monster" changes required to implement feature A or B. Maybe it's time to
consider a rewrite again?Cheers,
On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
I strongly suggest to anyone following the (too many) threads about
annotations to try the C# annotation and see what it allows. It goes
As far as I can see, C# annotations rely on two very important things:
- Compiler support. Compiler really knows a lot about what annotations do.
- Extensive library support. Annotations themselves are just passive
metadata, what makes them work is .net framework that uses them.This means to make annotations as useful in PHP we would have to have
substantial support in the engine (including bytecode caching
provisions, etc.) and some libraries that require very
latest-and-greatest version of PHP.Another thing is that we're not having some features that are used
extensively in C# annotations, main being named parameters support.I am saying this not to oppose the idea of annotations or the idea of
looking into C# and other languages (actually, I think anybody who talks
about it should look at least into what C# and Java do with it - and
also what Python does, which is completely different direction, just to
know other options). I'm just saying porting this to PHP may be less
than straightforward.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
-Clint
No. C++ is horrible. Very good read:
http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html
Oooh, a rewrite? Can we write it in an object oriented language this
time? Please? Pretty Please???:D
Stas,
I totally agree and Pierrick and I faced all these problems during the
creation of patch.
If PHP doesn't all have support required for a given feature, let's just
not only discuss feature, but also the required support too. Named
parameters is a great example. I'd also name another one,
ReflectionNamespace; namespaces are converted to strings and attached to
their classes during compile time and you can never reflect over them to
grab for example their names.
I even mentioned to Andi back in 2010 that ZE gets re-written every 5
years. That happened in 2000, 2005 and we're now hitting walls because of
"monster" changes required to implement feature A or B. Maybe it's time to
consider a rewrite again?Cheers,
On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev smalyshev@sugarcrm.com smalyshev@sugarcrm.comwrote:
Hi!
I strongly suggest to anyone following the (too many) threads about
annotations to try the C# annotation and see what it allows. It goesAs far as I can see, C# annotations rely on two very important things:
- Compiler support. Compiler really knows a lot about what annotations do.
- Extensive library support. Annotations themselves are just passive
metadata, what makes them work is .net framework that uses them.This means to make annotations as useful in PHP we would have to have
substantial support in the engine (including bytecode caching
provisions, etc.) and some libraries that require very
latest-and-greatest version of PHP.Another thing is that we're not having some features that are used
extensively in C# annotations, main being named parameters support.I am saying this not to oppose the idea of annotations or the idea of
looking into C# and other languages (actually, I think anybody who talks
about it should look at least into what C# and Java do with it - and
also what Python does, which is completely different direction, just to
know other options). I'm just saying porting this to PHP may be less
than straightforward.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
-Clint
It's a pretty decent read, but the major point that his article about
the virtues of C misses a huge mark. Software written in C, when they
become of sufficient size become completely impossible to keep track of.
A function that is related to a zend_function struct could be placed
anywhere, in any file and can be named in any way. Finding it is like
looking for a needle in a haystack, then you add macros.
When I first started with working with the php-core I was doing
everything wrong because it's a big mess, that's what happens with C, it
has no organization requirements whatsoever and unless everyone who is
working on the project is highly organized in the same fashion it will
become a disorganized mess.
Sure, C++ adds a lot of things that can overly complicate things but
at the very least it requires organization, something that most projects
sorely need.
Even so, C++ is not the only object oriented language out there.
-Clint
No. C++ is horrible. Very good read:
http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.htmlOooh, a rewrite? Can we write it in an object oriented language this
time? Please? Pretty Please???:D
Stas,
I totally agree and Pierrick and I faced all these problems during the
creation of patch.
If PHP doesn't all have support required for a given feature, let's just
not only discuss feature, but also the required support too. Named
parameters is a great example. I'd also name another one,
ReflectionNamespace; namespaces are converted to strings and attached to
their classes during compile time and you can never reflect over them to
grab for example their names.
I even mentioned to Andi back in 2010 that ZE gets re-written every 5
years. That happened in 2000, 2005 and we're now hitting walls because of
"monster" changes required to implement feature A or B. Maybe it's time to
consider a rewrite again?Cheers,
On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev smalyshev@sugarcrm.com smalyshev@sugarcrm.comwrote:
Hi!
I strongly suggest to anyone following the (too many) threads about
annotations to try the C# annotation and see what it allows. It goesAs far as I can see, C# annotations rely on two very important things:
- Compiler support. Compiler really knows a lot about what annotations do.
- Extensive library support. Annotations themselves are just passive
metadata, what makes them work is .net framework that uses them.This means to make annotations as useful in PHP we would have to have
substantial support in the engine (including bytecode caching
provisions, etc.) and some libraries that require very
latest-and-greatest version of PHP.Another thing is that we're not having some features that are used
extensively in C# annotations, main being named parameters support.I am saying this not to oppose the idea of annotations or the idea of
looking into C# and other languages (actually, I think anybody who talks
about it should look at least into what C# and Java do with it - and
also what Python does, which is completely different direction, just to
know other options). I'm just saying porting this to PHP may be less
than straightforward.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
-Clint
--
-Clint
2013/1/11 Clint Priest cpriest@zerocue.com
....
Even so, C++ is not the only object oriented language out there.-Clint
I could not resist the urge to suggest D as an option :) Sorry for this
troll attempt.
Well, there is Quercus out there in the wild, they did it. Sure a total
rewrite will give opportunity to correct many questionable choices and bad
implementations. But is it really feasible?
Arvids.
Hi!
A function that is related to a zend_function struct could be placed
anywhere, in any file and can be named in any way. Finding it is like
looking for a needle in a haystack, then you add macros.
You can do macros in C++ too, and you can have detached functions too.
And it is perfectly possible to make mess with classes, I have seen it
many times. Thinking that the language would somehow make you write good
code is an illusion. It can help you or fail to help you, but it can
never make you. C has tools to help you, though some of them aren't as
powerful as I would wish for, it still has them.
When I first started with working with the php-core I was doing
everything wrong because it's a big mess, that's what happens with C, it
It has nothing to do with C. Thinking that if PHP core was written in
<insert other language here> you would instantly get what's going on
after 3 minutes looking in the code is, again, an illusion. PHP core is
complex, because it does complex things. It also somewhat messy as any
organic growth project becomes after 15 years. Nothing has anything to
do with the language. You don't need C++ to not put new zend_hash
functions into zend_compile.c. You just need common sense and knowledge
how the project works.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
A function that is related to a zend_function struct could be placed
anywhere, in any file and can be named in any way. Finding it is like
looking for a needle in a haystack, then you add macros.
You can do macros in C++ too, and you can have detached functions too.
And it is perfectly possible to make mess with classes, I have seen it
many times. Thinking that the language would somehow make you write good
code is an illusion. It can help you or fail to help you, but it can
never make you. C has tools to help you, though some of them aren't as
powerful as I would wish for, it still has them.When I first started with working with the php-core I was doing
everything wrong because it's a big mess, that's what happens with C, it
It has nothing to do with C. Thinking that if PHP core was written in
<insert other language here> you would instantly get what's going on
after 3 minutes looking in the code is, again, an illusion. PHP core is
complex, because it does complex things. It also somewhat messy as any
organic growth project becomes after 15 years. Nothing has anything to
do with the language. You don't need C++ to not put new zend_hash
functions into zend_compile.c. You just need common sense and knowledge
how the project works.
That's true, but you can't put a method on a ZendHash class without
defining it within the class definition. I forget that C++ does let you
actually implement that function outside of the class definition, but
it's not a method of the class if it's not in the class definition.
I've gotten too use to the way PHP does it where all of the code for the
class is within the class definition it's-self, not quite the same as C++.
Can we re-write PHP with PHP? ;)
--
-Clint
Can we re-write PHP with PHP? ;)
Anthony and Nikita are already on it: https://github.com/ircmaxell/PHPPHP
That is seriously funny....
Can we re-write PHP with PHP? ;)
Anthony and Nikita are already on it: https://github.com/ircmaxell/PHPPHP
Not really insane.
PHPPHP is very powerful. Imagine someone that have no idea about C but
would love to propose something.
Just fork the project, add the desired support in PHP and propose here. I
guarantee it'll be easier to understand the caveats and the final patch
easily.
Cheers,
That is seriously funny....
On Jan 11, 2013, at 11:35 PM, Levi Morrison morrison.levi@gmail.com
wrote:Can we re-write PHP with PHP? ;)
Anthony and Nikita are already on it:
https://github.com/ircmaxell/PHPPHP--
--
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
In a semi-joke but oddly real concept. I get that the language proposals
(c++) are half jokes. But if we're going down that road, why don't we
consider rpython and building on top of HippyVM that's already partially
built... It would have a number of advantages over C:
- It compiles to C, so should generate portable code.
- Can support JIT compilation for better performance
- Has proven its performance already (even without JIT)
- It's a higher level language with memory management (no need to worry
about frees and the like) - It gives us all our nice OOP features (which can make certain tasks FAR
easier).
A not-so-serious, but half-serious idea...
Anthony
On Sat, Jan 12, 2013 at 10:58 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:
Not really insane.
PHPPHP is very powerful. Imagine someone that have no idea about C but
would love to propose something.
Just fork the project, add the desired support in PHP and propose here. I
guarantee it'll be easier to understand the caveats and the final patch
easily.Cheers,
On Sat, Jan 12, 2013 at 12:57 AM, Clint Priest cpriest@zerocue.com
wrote:That is seriously funny....
On Jan 11, 2013, at 11:35 PM, Levi Morrison morrison.levi@gmail.com
wrote:Can we re-write PHP with PHP? ;)
Anthony and Nikita are already on it:
https://github.com/ircmaxell/PHPPHP--
--
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
On Sat, Jan 12, 2013 at 7:35 AM, Levi Morrison morrison.levi@gmail.comwrote:
Can we re-write PHP with PHP? ;)
Anthony and Nikita are already on it: https://github.com/ircmaxell/PHPPHP
--
Just wished to express my respect for Anthony and Nikita for creating such
a awesome and cool project ! :)
I'll fork and start investigate it as soon as I'll get some free time and
will be happy to contribute!
I would definitely vote "No" on object oriented. I'd vote for C++ but
SOLELY because templates. I'd stay away from classes as they generally
hurt performance.
Sorry for the off-topic comment :)
Oooh, a rewrite? Can we write it in an object oriented language this time?
Please? Pretty Please???:D
Stas,
I totally agree and Pierrick and I faced all these problems during the
creation of patch.
If PHP doesn't all have support required for a given feature, let's just
not only discuss feature, but also the required support too. Named
parameters is a great example. I'd also name another one,
ReflectionNamespace; namespaces are converted to strings and attached to
their classes during compile time and you can never reflect over them to
grab for example their names.
I even mentioned to Andi back in 2010 that ZE gets re-written every 5
years. That happened in 2000, 2005 and we're now hitting walls because of
"monster" changes required to implement feature A or B. Maybe it's time to
consider a rewrite again?Cheers,
On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev
smalyshev@sugarcrm.comwrote:Hi!
I strongly suggest to anyone following the (too many) threads about
annotations to try the C# annotation and see what it allows. It goesAs far as I can see, C# annotations rely on two very important things:
- Compiler support. Compiler really knows a lot about what annotations
do.- Extensive library support. Annotations themselves are just passive
metadata, what makes them work is .net framework that uses them.This means to make annotations as useful in PHP we would have to have
substantial support in the engine (including bytecode caching
provisions, etc.) and some libraries that require very
latest-and-greatest version of PHP.Another thing is that we're not having some features that are used
extensively in C# annotations, main being named parameters support.I am saying this not to oppose the idea of annotations or the idea of
looking into C# and other languages (actually, I think anybody who talks
about it should look at least into what C# and Java do with it - and
also what Python does, which is completely different direction, just to
know other options). I'm just saying porting this to PHP may be less
than straightforward.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
-Clint
Hi,
I suggest you start defining action items in the RFC. After reading what
Stas and others say, this looks like too big a task to discuss in itself,
so it should be definitely be broken down.
You will probably find that as it is broken down, actual development
support will surface by itself.
Regards,
David
On Thu, Jan 10, 2013 at 9:49 PM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:
Stas,
I totally agree and Pierrick and I faced all these problems during the
creation of patch.
If PHP doesn't all have support required for a given feature, let's just
not only discuss feature, but also the required support too. Named
parameters is a great example. I'd also name another one,
ReflectionNamespace; namespaces are converted to strings and attached to
their classes during compile time and you can never reflect over them to
grab for example their names.
I even mentioned to Andi back in 2010 that ZE gets re-written every 5
years. That happened in 2000, 2005 and we're now hitting walls because of
"monster" changes required to implement feature A or B. Maybe it's time to
consider a rewrite again?Cheers,
On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev <smalyshev@sugarcrm.com
wrote:
Hi!
I strongly suggest to anyone following the (too many) threads about
annotations to try the C# annotation and see what it allows. It goesAs far as I can see, C# annotations rely on two very important things:
- Compiler support. Compiler really knows a lot about what annotations
do.- Extensive library support. Annotations themselves are just passive
metadata, what makes them work is .net framework that uses them.This means to make annotations as useful in PHP we would have to have
substantial support in the engine (including bytecode caching
provisions, etc.) and some libraries that require very
latest-and-greatest version of PHP.Another thing is that we're not having some features that are used
extensively in C# annotations, main being named parameters support.I am saying this not to oppose the idea of annotations or the idea of
looking into C# and other languages (actually, I think anybody who talks
about it should look at least into what C# and Java do with it - and
also what Python does, which is completely different direction, just to
know other options). I'm just saying porting this to PHP may be less
than straightforward.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Hi!
parameters is a great example. I'd also name another one,
ReflectionNamespace; namespaces are converted to strings and attached to
their classes during compile time and you can never reflect over them to
grab for example their names.
I still can't understand why you need ReflectionNamespace. Namespaces
are just strings. If you have class name \Foo\bar\Baz, \Foo is
namespace, \Foo\bar is namespace, and both can be created by splitting
class name. For me, it's like asking for runtime support for #define in
C - I don't even understand how such thing can be working. Can you
explain what you mean here?
I even mentioned to Andi back in 2010 that ZE gets re-written every 5
years. That happened in 2000, 2005 and we're now hitting walls because
of "monster" changes required to implement feature A or B. Maybe it's
time to consider a rewrite again?
Rewrite of what? With what purpose? And who will be doing it?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
I think you hit a nail here.
Am 10.01.2013 um 21:36 schrieb Stas Malyshev smalyshev@sugarcrm.com:
Another thing is that we're not having some features that are used
extensively in C# annotations, main being named parameters support.
To make sure we are not providing a somewhat cumbersome implementation, let’s start tackling named parameters first. It’s another long standing feature. We will most likely need named parameters for convenient annotations anyway. We have an (really old) RFC for that: https://wiki.php.net/rfc/namedparameters.
cu,
Lars
Hello,
Well, I've been reading internals for years and never replied. But I think
this time I have to share my thoughts.First of all I understand Rasmus and Stas position on holding PHP as simple
as it is. It's great and in the same way it's wrong. As Anthony mentioned
PHP evolves, and PHP is being used not only by designers who want to create
a simple corp site which by the way move to Rails, but mostly by thousands
of web agencies, developers and senior developers who constantly using
different languages and technologies. We have Ruby with all the sugar it
gives, we have Java with all enterprise mess it has. And we have PHP.I don't think I need to advocate OOP here, and I agree with Rasmus that we
need to stay simple. But we don't need to copy all those things from Java
for example, even Java world has Play! Framework which is great and gives
simpleness to the developer. We all know how annotations are being used by
Symfony or Doctrine and I don't think we need to create all the mess it has
in Java world. We all know the problems it give, why not to eliminate it
and create a new, PHP's vision of things. Right now all discussions are
being held like we will never implement annotations because we need to copy
it from Enterprise Java. But we don't need Java annotations, we need our
own. Constantly decline great futures just because some designer wouldn't
understand it is wrong by all means.PHP is great for web development, let's stick to it. Give us a chance to
create frameworks, which can use Annotations, DI, IoC, Factories,
Decorators and all others patterns to allow regular designer to create a
simple site with few lines of code.--
Kind Regards,Ignat Tuganov
Chief Information OfficerOffice Phone: +7 (812) 640-8022
E-Mail \ Gtalk: it@cloudmill.ru
CloudMill LLC
191015, 3 K Furazhnyi Lane, office #317, Saint-Petersburg, Russia
hi,
another thing to keep in mind:
most PHP frameworks out there has a faster development cycle and less of an
userbase than us(as every PHP framework user is a PHP user ofc.), so if
they make a bad design decision it is usually easier for them to fix it and
it has less of an impact and they have more people with the ability to fix
up any technical problems, as it is reasonably easy to find somebody with
the neccessary skills and knowledge required to fix the problem.
of course now that we introduced the new release process, hopefully we will
have faster release cycles, and some of the popular frameworks started
planning/introducing LTS releases with longer support cycle.
but still, we have to be careful about what do we introduce to the
language, because we have to support it for at least like minor 3 releases(
we introduce it in 7.2, deprecate it in 7.3 and remove it in 8.0 for
example).
back in the early symfony days using Singletons everywhere seemed like a
good idea, currently the general consensus is that it is an anti-pattern,
and only in a handful of use-cases is it a good idea using it.
similar thing happened with ORMs, first ORM meant pretty much using the
activerecord pattern, now the general consensus seems to be to use the data
mapper pattern instead.
if we too eager to include new hip stuff, it can happen that we will get
stuck with a half-baked solution which we have to support years after that
the cool guys already moved to something else.
the other thing that I mentioned is the difference between the required
skills needed to fix up bad implementations:
there aren't that many people familiar with the php-internals (and this
isn't the easier skill to pick up, as we somehow lack in quality
documentation on the internals part), even less people are familiar with
the parser, ZendEngine, and APC.
just some of the recent examples:
- traits was a nice RFC, complete patch, has an active author, years of
discussion, and it still needed a huge amount of work/refact to make it
play nicely with some edge-cases and with APC. (kudos to Stefan and
Dmitiry) - the finally feature: it was almost completely rewritten after the RFC
with the initial patch was voted and accepted (kudos to Laruence and Dmitry) - introducing generators also needed some love (a few segfaults in
edge-cases AFAIR and making it work together with finally kudos to Nikita
and Dmitry).
So I think the current problems are the following:
- users won't migrate to new php version until some of the top pecl exts
having issues with the new version (apc was a really obvious showstopper
for the php5.4 adoptation for example). - currently voting is more about wanting the feature or not, and not
about wanting/accepting the feature with the current implementation. this
can result in situations when something is accepted and merged, but it has
to be fixed/maintained, and that sucks when the work happens to require the
help of those who voted no based on their understanding on the problems of
the proposed rfc/patch. - we don't have enough QA exposure, so some of the problems will only
surface after the first final release (the implementation problems of
traits for example). - there are key areas where we lack active people (ZE, APC, etc.).
- the previous (nonexistent) release process made us really slow on
fixing/removing things:
http://blog.roshambo.org/a-brief-unofficial-history-about-register_globals-in-php/(it
was removed in 5.4.0 which was released 2012 Marc 01.) It took more
than 10 years to remove it since the time it was first accepted as a bad
decision to include. - the new release process allows/mandates planned and faster release
cycles, but it also means that we can only remove features in major version
jumps, which would either result in more frequent major feature bumps or
long gaps between times when we can remove features. - and yeah, I think that php means a lot of different things to a lot of
different people, so most of the times there can and will be arguments
whether or not it is a good idea or the 'php way' to include something. but
as long as we resolve those conflicts in civil manners and not using some
kind of fallacy (or making intentionally confusing/incomplete RFCs and
pushing through them the voting) it should be fine.
Sorry for the wall-of-text: 'If I Had More Time, I Would Have Written a
Shorter Letter'
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu