Re: [PHP-DEV] towards the next 5.3 release
On 15.02.2009, at 17:18, Marcus Boerger wrote: Hello Stanislav, Friday, February 13, 2009, 7:03:30 AM, you wrote: Hi! it should actually be a hard error. As we always claim PHP follows pure IS-A relation ships. I feel very uneasy with hard errors on something that is not indeed an error preventing engine from continuing. I.e. my (personal) opinion is that if the engine can move forward, even with some assumption, it should. IMHO it's like having undefined variables, etc. It makes PHP less strict, but I'd say it's not necessarily a bad thing. Hard as in E_RECOVERABLE_ERROR of course, since you are right that the engine indeed can continue. Thats almost as useless. If you make it E_RECOVERABLE_ERROR .. it essentially prevents people from modifying the method signatures in a non academic OO manner, which I think is not the point of PHP. E_STRICT reminds people that they are doing the wrong thing in academic terms, which however might very well make sense in business terms non the less. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
Hi! it should actually be a hard error. As we always claim PHP follows pure IS-A relation ships. I feel very uneasy with hard errors on something that is not indeed an error preventing engine from continuing. I.e. my (personal) opinion is that if the engine can move forward, even with some assumption, it should. IMHO it's like having undefined variables, etc. It makes PHP less strict, but I'd say it's not necessarily a bad thing. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
Hello Johannes,
Thursday, February 5, 2009, 8:02:47 PM, you wrote:
On Thu, 2009-02-05 at 10:36 -0800, Sebastian Bergmann wrote:
Johannes Schlüter wrote:
- No typehint, as it is now, #47206 Expected / to be documented,
incompatible with 5.2.6-5.2.8 but compatible with most other 5.2
versions
Could we extend the arginfo system to allow for multiple typehints? Of
course the Reflection API would have to support this :-/
Of course we could, we'd just have to change a structure and
zend_verify_arg_class_kind() and of course the language syntax to allow
something like function foo(A|B $bar) {} but this still would mean to
break source compatibility in a bad way here as the user's code would
have to follow the signature and won't be able to be 5.2 and 5.3
compatible in one file.
I actually think we only need this as an internal option and not for
reflection. For user code and reflection we would want to add support
for plain object (any class) type hinting - oh wait I said that before.
Right, my suggestion was to di:
function foo(Class $object) {}
It got rejected becuase I used the existing keyword ;class' rather then
inventing a new one that will in any case create a massive amount of new
issues (as with any new keyword). The only wayt out would be using magic
indication, as in two underscores. For instance:
function foo(__Object__ $object) {}
Internally this obviously requires a change of the API and needs to be
done now, prior to 5.3.0.
For internal functions, we can get more precise, by providing a new 'i'
option in zend_parse_args. That would take the allowed classes from a
zend_class_entry**, with the last one being NULL.
(But well, it anyway already got rejected. So I guess we just live with
the problems. And changing it now would come with the risk of another
delay, which would of course be the worst thing ever).
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
Hello Stanislav, it should actually be a hard error. As we always claim PHP follows pure IS-A relation ships. Tuesday, February 3, 2009, 8:42:51 PM, you wrote: Hi! http://bugs.php.net/bug.php?id=46984 - E_STRICT I think overriding foo($x) with foo($x, $y) - with both parameters required - leads to calls to foo with one argument be wrong for child - thus violating LSP and warranting E_STRICT. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
On 08.02.2009, at 15:36, Marcus Boerger wrote: it should actually be a hard error. As we always claim PHP follows pure IS-A relation ships. Not sure we claimed PHP did anything pure ever. Or when we claim anything to begin with. Maybe we also claim that we are a glue language optimized for the web. I think that would imply that it would try to keep going unless the engine is in an unstable state. So if you ask me about what we should claim if anything .. is that we can notify a user if he breaks the IS-A relationship, but that we will not force a rewrite if you have coded yourself into a corner. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
Maybe we can first collect a list here on internals@ on what apps have been successfully been run on 5.3 and whether they required any tweaking. If after we make a list there's still need to reach out I'd be happy to do some of that. FWIW, I've some casual testing with Habari and 5.3 and we haven't had any problems since ArrayObject was fixed, as far as I know. S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] towards the next 5.3 release
-Original Message- From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org] Sent: Friday, February 06, 2009 11:57 PM To: Andi Gutmans Cc: php-dev List Subject: Re: [PHP-DEV] towards the next 5.3 release Well we have established the primary testers mailinglist for this purpose. However the current release plan only includes mailing this list when the RC stage has been reached: http://www.php.net/reST/php-src/README.RELEASE_PROCESS So obviously this list can be used to get in contact with this group of projects. Maybe it makes sense to include them in x.y.0 releases. Then again the plan was to mail them once we hit RC1 anyways ... OK that's good although it may make sense to push that up to beta. In the past we have looked at Release Candidates as (We think it's ready to release and if no one finds critical bugs we could just rename the package). I doubt this is where you think we're at now and it's more about making sure we get broader testing. It's a bit of a chicken and egg so I understand the benefits of calling it RC. I guess what I was suggesting was that we at least have folks do a quick sanity with applications so we feel good about going into the RC. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] towards the next 5.3 release
-Original Message- From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org] Sent: Tuesday, February 03, 2009 5:42 AM To: php-dev List Subject: [PHP-DEV] towards the next 5.3 release --snip-- 5) upgrading guide --snip-- RC really signifies a feature complete + should be releasable state. I think a good step before would be to reach out to some of the popular PHP application authors and see if they can give b1 a try. This will give us input for upgrading guide and it may raise some issues. Maybe we can first collect a list here on internals@ on what apps have been successfully been run on 5.3 and whether they required any tweaking. If after we make a list there's still need to reach out I'd be happy to do some of that. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
I'd be happy to give this a whirl on the project here and report back: geeklog.net. I'm assuming it'll run just fine. I had it running under alpha3 fine. --Tony On Fri, Feb 6, 2009 at 8:12 PM, Andi Gutmans a...@zend.com wrote: -Original Message- From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org] Sent: Tuesday, February 03, 2009 5:42 AM To: php-dev List Subject: [PHP-DEV] towards the next 5.3 release --snip-- 5) upgrading guide --snip-- RC really signifies a feature complete + should be releasable state. I think a good step before would be to reach out to some of the popular PHP application authors and see if they can give b1 a try. This will give us input for upgrading guide and it may raise some issues. Maybe we can first collect a list here on internals@ on what apps have been successfully been run on 5.3 and whether they required any tweaking. If after we make a list there's still need to reach out I'd be happy to do some of that. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tony Bibbs Email: t...@tonybibbs.com Phone: 515.554.8046 Twitter: tonybibbs Skype: tonybibbs Web: http://www.tonybibbs.com
Re: [PHP-DEV] towards the next 5.3 release
On Wed, 2009-02-04 at 13:12 +0100, David Zülke wrote:
Am 03.02.2009 um 14:41 schrieb Lukas Kahwe Smith:
http://bugs.php.net/bug.php?id=47206 - XSLT
I looked through the CVS logs, could you confirm I understand it right:
The type hint was added in 5.2.6, and will be gone again in 5.2.9, so
the only PHP releases with DOMDocument type hints there are 5.2.6,
5.2.7 and 5.2.8?
I think independently from what we do in 5.3 we will have
incompatibilities between versions here which can't be worked-around in
userland (I don't consider if (version_compare(...)) { class ... } else
{ class ... } a proper workaround)
So here are three choices:
- The DOMDoument typehint is certainly wrong.
- Adding an interface is lots of additional trouble (user code will
break again, no proper way for users to be 5.2 and 5.3 compatible)
- No typehint, as it is now, #47206 Expected / to be documented,
incompatible with 5.2.6-5.2.8 but compatible with most other 5.2
versions
After reading this thread and some limited private discussion I think
the last option is the best.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
On 05.02.2009, at 17:32, Johannes Schlüter wrote:
On Wed, 2009-02-04 at 13:12 +0100, David Zülke wrote:
Am 03.02.2009 um 14:41 schrieb Lukas Kahwe Smith:
http://bugs.php.net/bug.php?id=47206 - XSLT
I looked through the CVS logs, could you confirm I understand it
right:
The type hint was added in 5.2.6, and will be gone again in 5.2.9, so
the only PHP releases with DOMDocument type hints there are 5.2.6,
5.2.7 and 5.2.8?
I think independently from what we do in 5.3 we will have
incompatibilities between versions here which can't be worked-around
in
userland (I don't consider if (version_compare(...)) { class ... }
else
{ class ... } a proper workaround)
So here are three choices:
- The DOMDoument typehint is certainly wrong.
- Adding an interface is lots of additional trouble (user code will
break again, no proper way for users to be 5.2 and 5.3 compatible)
- No typehint, as it is now, #47206 Expected / to be documented,
incompatible with 5.2.6-5.2.8 but compatible with most other 5.2
versions
After reading this thread and some limited private discussion I think
the last option is the best.
+1
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] towards the next 5.3 release
Johannes Schlüter wrote: - No typehint, as it is now, #47206 Expected / to be documented, incompatible with 5.2.6-5.2.8 but compatible with most other 5.2 versions Could we extend the arginfo system to allow for multiple typehints? Of course the Reflection API would have to support this :-/ -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
On Thu, 2009-02-05 at 10:36 -0800, Sebastian Bergmann wrote:
Johannes Schlüter wrote:
- No typehint, as it is now, #47206 Expected / to be documented,
incompatible with 5.2.6-5.2.8 but compatible with most other 5.2
versions
Could we extend the arginfo system to allow for multiple typehints? Of
course the Reflection API would have to support this :-/
Of course we could, we'd just have to change a structure and
zend_verify_arg_class_kind() and of course the language syntax to allow
something like function foo(A|B $bar) {} but this still would mean to
break source compatibility in a bad way here as the user's code would
have to follow the signature and won't be able to be 5.2 and 5.3
compatible in one file.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
Johannes Schlüter wrote:
Of course we could, we'd just have to change a structure and
zend_verify_arg_class_kind() and of course the language syntax to allow
something like function foo(A|B $bar) {} but this still would mean to
This should, of course, only be for built-in functions and methods. But
yeah, it probably does more harm than good.
It just sucks, IMHO, that some functions and methods will not have
Reflection API metadata because the same arginfo structure is used for
two things. But I will shut up now.
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
Sebastian Bergmann wrote: It just sucks, IMHO, that some functions and methods will not have Reflection API metadata because the same arginfo structure is used for two things. That did not come out right, nevermind. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
Hi!
Of course we could, we'd just have to change a structure and
zend_verify_arg_class_kind() and of course the language syntax to allow
something like function foo(A|B $bar) {} but this still would mean to
Maybe just use a plain old if()? :) I understand that is super-uncool
bit we really don't have to invent another mini-php there to specify
argument types (what if I want A and B, but not C which extends B, but
also null would be OK, and strings A and B too?)
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
David Zülke wrote: Am 03.02.2009 um 14:41 schrieb Lukas Kahwe Smith: http://bugs.php.net/bug.php?id=47206 - XSLT I looked through the CVS logs, could you confirm I understand it right: The type hint was added in 5.2.6, and will be gone again in 5.2.9, so the only PHP releases with DOMDocument type hints there are 5.2.6, 5.2.7 and 5.2.8? That's correct. The addition in 5.2.6 was a BC break and is fixed in 5.2.9 Rob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
Rob Richards wrote: The addition in 5.2.6 was a BC break and is fixed in 5.2.9 Removing the type-hint is only a short-term fix, IMHO. A better solution would be to introduce a marker interface that is implemented by the respective classes of the XML extensions involved and use said interface in the type hint. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
Am 03.02.2009 um 14:41 schrieb Lukas Kahwe Smith: http://bugs.php.net/bug.php?id=47206 - XSLT I looked through the CVS logs, could you confirm I understand it right: The type hint was added in 5.2.6, and will be gone again in 5.2.9, so the only PHP releases with DOMDocument type hints there are 5.2.6, 5.2.7 and 5.2.8? Thanks, - David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] towards the next 5.3 release
Rob Richards wrote: I might agree if PHP were strictly an OO language, but it's not. I think part of the problem is that the same information, arginfo, is used for things: provide metadata for the Reflection API and type hinting of internal functions/methods. When I added the arginfo metadata to XSLTProcessor last year I was not aware of the latter purpose. I only wanted to fix the missing metadata for reflection issue. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
Hi: I just reopend http://bugs.php.net/bug.php?id=43817 (opendir() fails on Windows...) and marked the version 5.3.0beta1. --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
Hi! http://bugs.php.net/bug.php?id=46984 - E_STRICT I think overriding foo($x) with foo($x, $y) - with both parameters required - leads to calls to foo with one argument be wrong for child - thus violating LSP and warranting E_STRICT. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
On Tue, 3 Feb 2009, Stanislav Malyshev wrote: http://bugs.php.net/bug.php?id=46984 - E_STRICT I think overriding foo($x) with foo($x, $y) - with both parameters required - leads to calls to foo with one argument be wrong for child - thus violating LSP and warranting E_STRICT. I agree with that Stas, this shouldn't change. regards, Derick -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org twitter: derickrethans -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
Lukas Kahwe Smith wrote:
Hi,
I also just reopened:
http://bugs.php.net/bug.php?id=46026
Not sure if Greg has time ..
Actually, this was more complex than originally stated, in that this
code is incorrect:
if (SUCCESS == zend_hash_find(HASH_OF(filterparams), concatenated,
sizeof(concatenated), (void **) tmpzval) ) {
-SEPARATE_ZVAL(tmpzval);
-convert_to_boolean_ex(tmpzval);
data-expect_concatenated = Z_LVAL_PP(tmpzval);
-zval_ptr_dtor(tmpzval);
tmpzval = NULL;
}
The reason being that it incorrectly uses whatever the zval is, thus any
hash table or object would evaluate to true, even an empty array or object.
Thus, the correct fix is the one implemented in zlib_filter.c, and I've
ported it over. It involves using a temporary zval, zval_copy_ctor()ing
it, and then convert_to_boolean_ex()ing it, which leaves the original
zval alone (the SEPARATE_ZVAL call does not do this properly), and
provides a valid boolean value. I'll commit momentarily.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
On 03.02.2009, at 20:52, Greg Beaver wrote: Stanislav Malyshev wrote: Hi! http://bugs.php.net/bug.php?id=46984 - E_STRICT I think overriding foo($x) with foo($x, $y) - with both parameters required - leads to calls to foo with one argument be wrong for child - thus violating LSP and warranting E_STRICT. I agree. If $y were optional, the LSP is no longer violated, and the E_STRICT disappears, as expected. Opn-Bgs I agree. This is exactly what we have E_STRICT for .. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
Stanislav Malyshev wrote: Hi! http://bugs.php.net/bug.php?id=46984 - E_STRICT I think overriding foo($x) with foo($x, $y) - with both parameters required - leads to calls to foo with one argument be wrong for child - thus violating LSP and warranting E_STRICT. I agree. If $y were optional, the LSP is no longer violated, and the E_STRICT disappears, as expected. Opn-Bgs Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
