Rasmus
This is my worry as well. Especially when it comes to opcode cache
support. Most of the patches I see these days completely ignore the
opcode cache side of things which needs to change. For any large
language-level change, any implementation that doesn't also include an
APC diff, or at least a very complete explanation of how it will be
generally supported by opcode caches just isn't complete.
I see this as the exact wrong way a language should progress. The core
should not be bound to extensions, but the other way around. Otherwise it
creates this weird meta state...
While I do see your point, to me it's less of an issue that it breaks APC,
and more of an issue that APC's functionality is not in core.
I mean if an extension is SO important, that we can't release language
features without updating that extension, then it's a sign that it
shouldn't be an extension in the first place.
We wouldn't have this issue if APC was in core. As it is now, having it as
an external project just creates weird muddied waters...
So I guess my point is rather than passing the message that people making
language changes need to think about APC, I think the message should be
that APC needs to get into core (and should be made an initiative)... As it
stands now, it's just going to keep causing pain...
My $0.02 at least...
Anthony
<snip>Rasmus wrote:
This is my worry as well. Especially when it comes to opcode cache
support. Most of the patches I see these days completely ignore the
opcode cache side of things which needs to change. For any large
language-level change, any implementation that doesn't also include
an APC diff, or at least a very complete explanation of how it will
be generally supported by opcode caches just isn't complete.
So I guess my point is rather than passing the message that people
making language changes need to think about APC, I think the message
should be that APC needs to get into core (and should be made an
initiative)... As it stands now, it's just going to keep causing
pain...
It was a plan in the past, I think we should just do it - now.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
<snip>Rasmus wrote:
This is my worry as well. Especially when it comes to opcode cache
support. Most of the patches I see these days completely ignore the
opcode cache side of things which needs to change. For any large
language-level change, any implementation that doesn't also include
an APC diff, or at least a very complete explanation of how it will
be generally supported by opcode caches just isn't complete.So I guess my point is rather than passing the message that people
making language changes need to think about APC, I think the message
should be that APC needs to get into core (and should be made an
initiative)... As it stands now, it's just going to keep causing
pain...It was a plan in the past, I think we should just do it - now.
I fully 100% agree with that.
Reading Rasmus 5min ago on the other topic (annotations) made me think
about writing such a topic again. But Anthony's been faster ;-)
Rasmus, Anthony's arguments make full sense : if any Core feature addition
need to be thought so that APC need to be patched correctly, then we have
to move APC to Core.
Not having at least one default Opcode cache solution in Core, even
disabled by default in runtime configuration really is a nonsense.
And I guess this will solve the "PHP5.4 adoption problem" as well, you see
what I mean, so we won't meet it again in the future. That's been very bad
for 5.4 adoption, and for PHP itself though.
kindly,
Julien.Pauli
Hi!
It was a plan in the past, I think we should just do it - now.
If you mean moving the directory from pecl to ext/ - that's fine as long
as maintainers commit to keeping it in shape (last time, I remember, 5.4
support was lagging). If you mean more tight integration - see my
previous email why I think it would be a bad idea.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
It was a plan in the past, I think we should just do it - now.
If you mean moving the directory from pecl to ext/ - that's fine as
long as maintainers commit to keeping it in shape (last time, I
remember, 5.4 support was lagging). If you mean more tight integration
- see my previous email why I think it would be a bad idea.
I meant in ext/
cheers,
Derick
Rasmus
This is my worry as well. Especially when it comes to opcode cache support. Most of the patches I see these days completely ignore the opcode cache side of things which needs to change. For any large language-level change, any implementation that doesn't also include an APC diff, or at least a very complete explanation of how it will be generally supported by opcode caches just isn't complete.I see this as the exact wrong way a language should progress. The core
should not be bound to extensions, but the other way around. Otherwise
it creates this weird meta state...While I do see your point, to me it's less of an issue that it breaks
APC, and more of an issue that APC's functionality is not in core.
It effectively is a core extension. Many, perhaps even most, sites won't
upgrade to a new PHP version until there is solid APC support for it,
and as far as end-user visibility goes, they just see it as a php5-apc
package just like php5-mysql. Whether one is in core or not is invisible
to them. But yes, if it takes putting it in core to get developers to
pay attention, then that is what we will have to do.
It is however handy to be able to have a separate release schedule for
it and I like the separation and modularity of it. Having more of the
optional core extensions separated this way wouldn't necessarily be a
bad thing.
-Rasmus
Hi!
While I do see your point, to me it's less of an issue that it breaks
APC, and more of an issue that APC's functionality is not in core.
You are confusing specific extension with functionality. The problem is
not that specific extension (APC) is not in core, but that the proposal
makes functionality (bytecode caching) very hard. Having this
functionality work and possible is important. Having it in extension
works perfectly well and actually much better than if it would be in the
core, since it allows APC and other bytecode caches to experiment with
additional functionality and ideas (file stat caching, data caching,
optimizations, etc.) without destabilizing core. Having functionality
not in core but in extension is not a punishment or some kind of
statement of importance, it is just a good design that makes the thing
more flexible and opens more space to innovation and improvement.
We wouldn't have this issue if APC was in core. As it is now, having it
as an external project just creates weird muddied waters...
I do not see how what Rasmus said even relevant to APC being in core.
The same issue would be there anyway. How APC is compiled is completely
irrelevant here.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227