Hello internals,
let's make ext/pcre and ext/spl first class core components and not allow
to disable them.
SPL:
- influences a bunch of other stuff, and some extensions even behave
different whether SPL is shared or built-in, this is hard to realize
and understand for our users - was designed from the beginning to contain stuff that is standard in
the oo world, so non standard stuff should be moved to specialized
extensions like pecl/spl_types
- yet another core component and special case
- most important stuff could be moved to zend - but where to stop
- well nothing in spl belongs into the engine, in the same way that
nothing in ext/standard is in the engine.- zend engine has different license - i wouldn't allow the change
- there is already too much in the engine, actually we should move
stuff out of there - (oops/ouch, did i say this?)
- spl only utilizes the engine, it does not influence modify anything
there. - we want to be able to rely on SPL in run-tests.php
PCRE:
- used in a lot of stuff and influences stuff like SPL
beep, go back to square one - is anybody not using this one, seriously?
- other regex options suck
- we want to be able to rely on PCRE in run-tests.php
comments?
Best regards,
Marcus
Hello,
Hello internals,
let's make ext/pcre and ext/spl first class core components and not allow
to disable them.
I fail to see what:
class_implements
class_parents
iterator_count
iterator_to_array
spl_autoload_cal
spl_autoload_extensions
spl_autoload_functions
spl_autoload_register
spl_autoload_unregister
spl_autoload
spl_object_hash
do outside ZE2.
ArrayObject is a must have to fix a couple of important issues with
object properties and array. It is also a powerful way to work with
arrays.
Iterators are part of any modern language. They are often nicely
integrated with the core of its language. Why should they be
maintained in an extension in PHP?
- zend engine has different license - i wouldn't allow the change
Is it a no-no to any move? I would start to seriously worry about SPL if yes.
--Pierre
Hello Pierre,
Tuesday, June 5, 2007, 10:36:54 PM, you wrote:
Hello,
Hello internals,
let's make ext/pcre and ext/spl first class core components and not allow
to disable them.
I fail to see what:
class_implements
class_parents
oh yeah there is alway an exception, we could move that to the engine.
But once again i think that we sactually should move stuff out of the
engine. We should seperate code and engine better.
iterator_count
iterator_to_array
standard functionality around iterators. they have nothing to do inside
the engine. they are like any function in ext/standard, only this is
about oop.
spl_autoload_cal
spl_autoload_extensions
spl_autoload_functions
spl_autoload_register
spl_autoload_unregister
spl_autoload
all discussable as this really influences the engines behavior. The
reason was actually to be able to disable it be disabling SPL. Now if
we disallow disabling SPL we might eventually move all of tese into the
engine. But then once again. We should not move stuff into but out of
the engine.
spl_object_hash
Just a standard OOP function. Nothign that belongs into the engine.
All in all it appears we have a different point of view. I for one
would prefer having a seperation between engine and non engine stuff.
Where the Interfaces Iterator, IteratorAggregate, Traversable and the
classes stdClass and exception are the bridges between engine and
runtime system. As far as i get your point it is about keeping essential
core and core/engine influencing stuff into the engine.
I think everyone should answer the following question for him/herself:
Where do the array functions (including size) belong. Into the engine
or in ext/standard? If the latter, where does standard object stuff
belong the engine or ext/spl and where are the limits?
ArrayObject is a must have to fix a couple of important issues with
object properties and array. It is also a powerful way to work with
arrays.
Iterators are part of any modern language. They are often nicely
integrated with the core of its language. Why should they be
maintained in an extension in PHP?
because imho that is the way PHP is designed. You put stuff that belongs
together into an extension and assign responsibilities.
- zend engine has different license - i wouldn't allow the change
Is it a no-no to any move? I would start to seriously worry about SPL if yes.
It often has been a no-no in the past. And that resulted in a bunch of
function pointers inside the engine. Like error reporting or spprintf.
Furthermore it resulted in stuff like TSRM being seperate.
Best regards,
Marcus
Hello,
I sniped the rest as we can argue endlessly about what should be in or
out, I think I made my point :)
However, in case I did not make it, here it is:
Just a standard OOP function. Nothign that belongs into the engine.
If it is standard OO, it belongs to the engine, the core of the
language. And the PHP internals developers (as for any language
related decisions) should have the responsibility not a couple of
extension maintainers.
--Pierre
Hello Pierre,
Tuesday, June 5, 2007, 11:21:48 PM, you wrote:
Hello,
I sniped the rest as we can argue endlessly about what should be in or
out, I think I made my point
However, in case I did not make it, here it is:
Just a standard OOP function. Nothign that belongs into the engine.
If it is standard OO, it belongs to the engine, the core of the
language. And the PHP internals developers (as for any language
related decisions) should have the responsibility not a couple of
extension maintainers.
While the engine changes the language, SPL only faciliates what the engine
allows. For instance you can write any number of exceptions but SPL gives a
nice number of default exception classes with a documented semantics. It is
similar to the exception classes in C++/STL and there they are also not part
of the language but of the extension (STL in this case). And I tried to do
the same for PHP just as we did the same with ext/standard which hosts stuff
that is part of the C API rahther than the C lnaguage. Where sizof/count is
the exception to the rule. We have it in the ext while C/C++ have it in the
language. Well it returns size_t which is part of the API rather than the
language (damn broken design imo).
Best regards,
Marcus
let's make ext/pcre and ext/spl first class core components and not allow
to disable them.
Well, theoretically I can imagine reason why somebody would like to
disable them - e.g., if I need super-high-performance server and I
absolutely must squeeze out every last bit of cpu/memory usage and I
don't do neither SPL nor regular expressions - I might want to disable it.
In any case, I see the reasons why we want it enabled. But I'd like to
hear any reasons why we need it enabled - i.e. any vital stuff that
can't work with SPL/PCRE disabled?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
I might want to disable it.
In any case, I see the reasons why we want it enabled. But I'd like to
hear any reasons why we need it enabled - i.e. any vital stuff that
can't work with SPL/PCRE disabled?
I just listed two:
- the array bugs in object properties. There is no other work around
but to use ArrayObject. And this is rather critical. - The other functions I listed in my reply are also clearly ZE2 tasks
(they all implement what is missing now in the engine).
I can imagine a reason why one does not need PCRE. However it is
already enable by default and is part of each distro default package
as far I remember.
--Pierre
- the array bugs in object properties. There is no other work around
but to use ArrayObject. And this is rather critical.
Could you elaborate - which bugs?
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
- the array bugs in object properties. There is no other work around
but to use ArrayObject. And this is rather critical.Could you elaborate - which bugs?
A rude explanation was here:
There is also a bug report about this problem, I just can't find it.
--Pierre
Could you elaborate - which bugs?
A rude explanation was here:
I'm not sure I understand where is the bug. If your __get doesn't return
by reference, it can't be modified. That's how it's supposed to work. If
it returns by ref, it works.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Could you elaborate - which bugs?
A rude explanation was here:
I'm not sure I understand where is the bug. If your __get doesn't return
by reference, it can't be modified. That's how it's supposed to work. If
it returns by ref, it works.
Please check the bugs database. There was numerous reports about this
problem and there is no solution to use an object instead of an array
(object being reference, that solves the issue). It is far from
obvious that the current behavior is correct, read: it is not correct.
However, I'm not arguing about why or how this bug should be fixed but
that the only work 'round is in SPL. ArrayObject (and related) must be
in Zend, it is a core feature.
--Pierre
Please check the bugs database. There was numerous reports about this
problem and there is no solution to use an object instead of an array
I'm still not following, I tried modifying the example you gave making
__get return by reference and it worked just fine. I would gladly look
up the bug database, I just don't know what to look for since I still
don't know what the problem is.
However, I'm not arguing about why or how this bug should be fixed but
that the only work 'round is in SPL. ArrayObject (and related) must be
in Zend, it is a core feature.
I'm not so sure. For example, I'm sure sessions are user much more than
ArrayObject, but they aren't.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Hello Stanislav,
Wednesday, June 6, 2007, 9:06:13 AM, you wrote:
Please check the bugs database. There was numerous reports about this
problem and there is no solution to use an object instead of an array
I'm still not following, I tried modifying the example you gave making
__get return by reference and it worked just fine. I would gladly look
up the bug database, I just don't know what to look for since I still
don't know what the problem is.
However, I'm not arguing about why or how this bug should be fixed but
that the only work 'round is in SPL. ArrayObject (and related) must be
in Zend, it is a core feature.
I'm not so sure. For example, I'm sure sessions are user much more than
ArrayObject, but they aren't.Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
You are actually not allowed to change the signature. If you could add
or drop & from the signature then there is a bug in the engine. That is
what Pierre was referring to, the disability to change the signature.
Best regards,
Marcus
You are actually not allowed to change the signature. If you could add
or drop & from the signature then there is a bug in the engine. That is
what Pierre was referring to, the disability to change the signature.
You mean when you inherit class with __get defined? Why not?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Hello Stanislav,
it violates our pure is-a approach.
best regards
marcus
Wednesday, June 6, 2007, 9:52:51 AM, you wrote:
You are actually not allowed to change the signature. If you could add
or drop & from the signature then there is a bug in the engine. That is
what Pierre was referring to, the disability to change the signature.
You mean when you inherit class with __get defined? Why not?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Best regards,
Marcus
Hello Pierre,
it is neither a core feature nor does it blong into the engine. And
the real solution would be:
- proxies (object, property), (object, array index)
- another interface, say ArrayAccessByRef which allows to deal with
references, a few things can be done automatically but you can never
solve all issues - unless you're using proxies - also another interface for IteratorByRef that has function &__current()
might be interesting
Now the proxies caneasily be done in userspace once we have the ability
to overload get/set - i am actually thinking of doing something in
pecl/spl_types. And later might be done in the engine completely.
The interfaces however clearly belong into the engine.
best regards
marcus
Wednesday, June 6, 2007, 9:02:00 AM, you wrote:
Could you elaborate - which bugs?
A rude explanation was here:
I'm not sure I understand where is the bug. If your __get doesn't return
by reference, it can't be modified. That's how it's supposed to work. If
it returns by ref, it works.
Please check the bugs database. There was numerous reports about this
problem and there is no solution to use an object instead of an array
(object being reference, that solves the issue). It is far from
obvious that the current behavior is correct, read: it is not correct.
However, I'm not arguing about why or how this bug should be fixed but
that the only work 'round is in SPL. ArrayObject (and related) must be
in Zend, it is a core feature.
--Pierre
Best regards,
Marcus
- the array bugs in object properties. There is no other work around
but to use ArrayObject. And this is rather critical.Could you elaborate - which bugs?
A rude explanation was here:
There is also a bug report about this problem, I just can't find it.
This sounds very much related to a (still open) bug report I posted
http://bugs.php.net/bug.php?id=38102
Stanislav Malyshev wrote:
Well, theoretically I can imagine reason why somebody would like to
disable them - e.g., if I need super-high-performance server and I
absolutely must squeeze out every last bit of cpu/memory usage and I
don't do neither SPL nor regular expressions - I might want to disable it.
These people can and will hack on the source anyways. They will do stuff
like Yahoo is doing. They will not let themselves get stopped by
anything we put in :)
regards,
Lukas
The big reason for PCRE is the fact that other, rather important
extensions such as filter depend on it. SPL is also used by other
extensions, which could be a "need" reason.
let's make ext/pcre and ext/spl first class core components and
not allow
to disable them.Well, theoretically I can imagine reason why somebody would like to
disable them - e.g., if I need super-high-performance server and I
absolutely must squeeze out every last bit of cpu/memory usage
and I don't do neither SPL nor regular expressions - I might want
to disable it.
In any case, I see the reasons why we want it enabled. But I'd
like to hear any reasons why we need it enabled - i.e. any vital
stuff that can't work with SPL/PCRE disabled?Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/--
Ilia Alshanetsky
The big reason for PCRE is the fact that other, rather important
extensions such as filter depend on it. SPL is also used by other
extensions, which could be a "need" reason.
But you can run PHP without filter extension.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
let's make ext/pcre and ext/spl first class core components and not
allow
to disable them.
PCRE: +0.5
SPL: -1 (Just confuses me, never use it, don't need it)
ymmv
imho
.
.
.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
And to be absolutely clear about this: This will happen in HEAD (PHP 6)
only. Right? :)
--Jani
Hello internals,
let's make ext/pcre and ext/spl first class core components and not allow
to disable them.SPL:
- influences a bunch of other stuff, and some extensions even behave
different whether SPL is shared or built-in, this is hard to realize
and understand for our users- was designed from the beginning to contain stuff that is standard in
the oo world, so non standard stuff should be moved to specialized
extensions like pecl/spl_types
- yet another core component and special case
- most important stuff could be moved to zend - but where to stop
- well nothing in spl belongs into the engine, in the same way that
nothing in ext/standard is in the engine.
- zend engine has different license - i wouldn't allow the change
- there is already too much in the engine, actually we should move
stuff out of there - (oops/ouch, did i say this?)- spl only utilizes the engine, it does not influence modify anything
there.- we want to be able to rely on SPL in run-tests.php
PCRE:
- used in a lot of stuff and influences stuff like SPL
beep, go back to square one- is anybody not using this one, seriously?
- other regex options suck
- we want to be able to rely on PCRE in run-tests.php
comments?
Best regards,
Marcus
- other regex options suck
I would argue that. mb_ereg (which is powered by oniguruma) seems to
be way more interestingi (and it is faster too)
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
Hello Alexey,
but we already decided to obsolete mbstring in favor of ICU/PCRE in
PHP 6. Also we have no control over mbstring's license because the
license holder refuses to change mbstring library to PHP License.
best regards
marcus
Wednesday, June 6, 2007, 4:32:11 PM, you wrote:
- other regex options suck
I would argue that. mb_ereg (which is powered by oniguruma) seems to
be way more interestingi (and it is faster too)
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
Best regards,
Marcus
I see… well, then I guess I have a reason to make oniguruma extension,
which wouldn't be part of mbstring… but I guess I am getting offtopic
here
Hello Alexey,
but we already decided to obsolete mbstring in favor of ICU/PCRE in
PHP 6. Also we have no control over mbstring's license because the
license holder refuses to change mbstring library to PHP License.best regards
marcusWednesday, June 6, 2007, 4:32:11 PM, you wrote:
- other regex options suck
I would argue that. mb_ereg (which is powered by oniguruma) seems to
be way more interestingi (and it is faster too)--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/Best regards,
Marcus
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
Also we have no control over mbstring's license because the
license holder refuses to change mbstring library to PHP License.
why he has to ? the library is not derivated work of PHP, is a plain
non-sense to ask other people libraries or work to be under the PHP
license.
If we use the same rationale, is like asking IBM to license ICU under
the PHP license for use (or bundling) with PHP6.
Also we have no control over mbstring's license because the
license holder refuses to change mbstring library to PHP License.
why he has to ? the library is not derivated work of PHP, is a plain
non-sense to ask other people libraries or work to be under the PHP
license.If we use the same rationale, is like asking IBM to license ICU under
the PHP license for use (or bundling) with PHP6.
The difference is that we do not ship ICU with PHP, but we do ship Oniguruma library.
--
Wbr,
Antony Dovgal
As far as I understood, the problem is not oniguruma, which is
BSD-licensed, but libmbfl, which is LGPL-licenses according to
http://cvs.php.net/viewvc.cgi/php-src/ext/mbstring/README.libmbfl?revision=1.1&view=markup
but according to http://sourceforge.jp/projects/php-i18n/ it is BSD-licensed now
The difference is that we do not ship ICU with PHP, but we do ship Oniguruma library.
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
Hello internals,
let's make ext/pcre and ext/spl first class core components and not allow
to disable them.
+1, and PCRE was already discussed for PHP 6 like this:
http://php.net/~derick/meeting-notes.html#move-ereg-to-pecl
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org