Re: [PHP-DEV] [RFC - Discussion] Parameter Type Casting Hints
Hi, Lazare
This is something not obvious, at least for me, and should be handled in
the function itself.
Here it would be better to update the function *add()* that you could also
pass mixed and it will try to generate a *DateInterval *out of that or
whatever.
But that's another RFC.
Type-juggling applies just to weak-types like string, int, float and
boolean. I don't like to have this for resource, array or class excepted
they are compatible to each other (like array and SplFixedArray,
SplObjectStorage, ArrayIterator, ...)
If you have to do something special to get the expected type (like creating
a new object) type-juggling would not be the good-way to go.
Bye
Simon
2012/3/4 Lazare Inepologlou linep...@gmail.com
I wouldn't want people to put class typehints in there such as
function foo( (SomeClass) $foo)
Why not? I would definitely like something like that, in the future. Here
is an example:
class DateTime {
...
public function add( (DateInterval) $interval ) { ... }
...
}
$date = new DateTime;
$date-add( 'P3D' ); // string to DateInterval casting
$date-add( 3600 ); // int (seconds) to DateInterval casting
Personally, I find this to be much closer to free type-juggling PHP style
than the current implementation with type hints (
http://www.php.net/manual/en/datetime.add.php).
[ Actually, I would prefer even type hints to work like this. Check if the
passed argument if of the correct type and, if not, try to cast it. Failure
to do so will lead to the E_RECOVERABLE_ERROR as today. ]
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/4 Paul Dragoonis dragoo...@gmail.com
Can you make sure that only scalar or array casts can be done?
I wouldn't want people to put class typehints in there such as
function foo( (SomeClass) $foo)
- Paul.
On Sun, Mar 4, 2012 at 1:28 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
Hey all,
I've drafted an RFC for the Parameter type casting hint proposal that
I posted to before. Attached to the RFC is a patch that's proposed
for inclusion in core for functionality (it doesn't include news
entries, or documentation, or any of the other steps that would be
needed prior to commit).
https://wiki.php.net/rfc/parameter_type_casting_hints
Please provide feedback here on the implementation and RFC topics.
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for bug #60075
Hi all, I've made a patch for #60075 because it's a feature I'll find very useful. It's my first patch so it'd be great to get some feedback. https://bugs.php.net/bug.php?id=60075 Thanks. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
[PHP-DEV] '?=' with PHP5.3.10
OK what changed in the automatic updates from PHP5.3.9 to 5.3.10 that stops '?=' working when it was working previously? I do not recall the state of short_open_tag changing but was that 'defaulted' to off when previously it was on? I had thought that '?=' was discussed and had been left alone, but now I'm told that is only on PHP5.4.0 Something broke sites without any warning and it would have been nice to be told by that ISP that they were updating PHP anyway :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] '?=' with PHP5.3.10
On Mon, Mar 5, 2012 at 2:50 PM, Lester Caine les...@lsces.co.uk wrote: OK what changed in the automatic updates from PHP5.3.9 to 5.3.10 that stops '?=' working when it was working previously? I do not recall the state of short_open_tag changing but was that 'defaulted' to off when previously it was on? I had thought that '?=' was discussed and had been left alone, but now I'm told that is only on PHP5.4.0 Something broke sites without any warning and it would have been nice to be told by that ISP that they were updating PHP anyway :( In 5.4.0 the ?= will be always available regarding from the value of short_open_tag but that has nothing to do with 5.3, or your problem. as far as I can see, we didn't changed neither the php.ini-*files, nor the hard-coded default value for short_open_tag: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/main/main.c?view=annotate http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/configure.in?view=annotate http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/win32/build/config.w32.h.in?view=annotate http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/php.ini-production?view=annotate#l226 http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/php.ini-development?view=annotate#l226 if your ini files are the same as with the previous install, then my guess is that you (or your distributor) started compiling php with --disable-short-tags, and you didn't explicitly enable the short_open_tag from your php.ini that is, or we have a bug. :/ Tyrael -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] '?=' with PHP5.3.10
On Mon, 2012-03-05 at 13:50 +, Lester Caine wrote: OK what changed in the automatic updates from PHP5.3.9 to 5.3.10 that stops Nothing as a $ svn diff \ https://svn.php.net/repository/php/php-src/tags/php_5_3_9 \ https://svn.php.net/repository/php/php-src/tags/php_5_3_10 clearly shows. This must be due to configuration changes (--disable-short-tags or php.ini changes or something) johannes '?=' working when it was working previously? I do not recall the state of short_open_tag changing but was that 'defaulted' to off when previously it was on? I had thought that '?=' was discussed and had been left alone, but now I'm told that is only on PHP5.4.0 Something broke sites without any warning and it would have been nice to be told by that ISP that they were updating PHP anyway :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] '?=' with PHP5.3.10
Ferenc Kovacs wrote: On Mon, Mar 5, 2012 at 2:50 PM, Lester Caine les...@lsces.co.uk mailto:les...@lsces.co.uk wrote: OK what changed in the automatic updates from PHP5.3.9 to 5.3.10 that stops '?=' working when it was working previously? I do not recall the state of short_open_tag changing but was that 'defaulted' to off when previously it was on? I had thought that '?=' was discussed and had been left alone, but now I'm told that is only on PHP5.4.0 Something broke sites without any warning and it would have been nice to be told by that ISP that they were updating PHP anyway :( In 5.4.0 the ?= will be always available regarding from the value of short_open_tag but that has nothing to do with 5.3, or your problem. as far as I can see, we didn't changed neither the php.ini-*files, nor the hard-coded default value for short_open_tag: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/main/main.c?view=annotate http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/configure.in?view=annotate http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/win32/build/config.w32.h.in?view=annotate http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/php.ini-production?view=annotate#l226 http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/php.ini-development?view=annotate#l226 if your ini files are the same as with the previous install, then my guess is that you (or your distributor) started compiling php with --disable-short-tags, and you didn't explicitly enable the short_open_tag from your php.ini that is, or we have a bug. :/ I'm still waiting on an answer back from the ISP as to what they ACTUALLY did. In the meantime I've been around all the affected sites and changed things so they work. It's just annoying that I've had to spend most of the morning 'fire-fighting' something that should never have happened :( The sites will be moving onto machines under my control anyway, but that will take a while. I can't work with suppliers who take hours to even respond to a problem and don't provide update information. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bugs access request
Hi, As PHP (co)maintainer in Fedora, I sometime need to access security bugs which are private. Ex: https://bugs.php.net/bug.php?id=55500 Can I be granted for such access ? Regards, Remi. P.S. I already have an SVN account : remi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: HEADS UP: 5.4 branch is open again
On 2012-03-02, David Soria Parra d...@php.net wrote: just a heads up. The PHP_5_4 branch is open for commits again. Related: With 5.4.0 out... how soon will the cutover to git occur? -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
On 2012-03-02, Anthony Ferrara ircmax...@gmail.com wrote:
Well, there are a few questions about the implementation:
1. *Which* type casting rules should it follow?
a. Regular cast rules (like $foo = (int) $foo), where it converts
always without error?
b. Internal function cast rules, where it warnings on error and
prevents execution of the function.
c. Current type hinting rules, where if it can't convert cleanly it
E_RECOVERABLE_ERRORS
Personally, I like C the best. Where if it is passed an invalid
value, it attempts to cleanly convert, but errors out if it can't...
But I can see other arguments being made...
(c) seems the most sane option ot me as well.
2. Should (array) be supported? Perhaps. So at that point, foo(array
$bar) would do a strict check, and foo((array) $bar) would attempt
to cast. But my question would be: what would attempt to cast mean?
Should it error out if you pass foo(1)? That's what the internal
function cast rules do. And to me that's more obvious than silently
converting it to foo(array(1))...
Turn this around and look at it from the current state of PHP:
function foo($bar)
{
$bar = (array) $bar;
}
If you pass a value of 1 for $bar, $bar is then converted to array(1).
That's what I'd expect the following to do as well:
function foo((array) $bar)
{
}
It's casting, and clearly different than:
function foo(array $bar)
{
}
which is doing a typehint check.
3. Should references be supported? My feeling is yes, they should.
So if you do foo((array) $bar), it would cast the original value (if
possible) as well.
I personally would expect casting and references to be mutually
exclusive -- if you're casting, you're changing the value type, and I
wouldn't expect a destructive operation like this from passing a value
to a function/method call.
snip
5. What about BC breaks? Well, this entire patch (up to this point)
wouldn't require one. it's only adding the casting functionality
(which is not implemented today), so no problem. Existing code would
still function fine.
This is something that should be highlighted. I've seen a lot of folks
claiming type hinting is viral, and the arguments make no sense to me.
What your patch is offering is _opt_in_ type casting of function/method
arguments. You don't _have_ to write your functions or methods using
them, and for those who do, it should have no side effects on code
calling it.
I would _LOVE_ to see this as part of PHP.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] discussions, about a 5.3 EOL
On 2012-03-02, Pierre Joye pierre@gmail.com wrote: It should have been done before 5.4.0 was out, but better late than never. I put together four options here: https://wiki.php.net/rfc/php53eol I'm in favor of option #1, as it gives enough time to our users to migrate by reducing the maintenance period to only one year. Suggestions or comments welcome, Considering that 5.3 adoption is still eclipsed by 5.2 adoption, to be honest, it feels like doing 1 year bugfix + 1 year security fix is the minimum necessary. By the time we get good adoption of 5.3, it will already be EOL'd. :-/ -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] discussions, about a 5.3 EOL
On Mon, 2012-03-05 at 10:27 -0500, Matthew Weier O'Phinney wrote: On 2012-03-02, Pierre Joye pierre@gmail.com wrote: It should have been done before 5.4.0 was out, but better late than never. I put together four options here: https://wiki.php.net/rfc/php53eol I'm in favor of option #1, as it gives enough time to our users to migrate by reducing the maintenance period to only one year. Suggestions or comments welcome, Considering that 5.3 adoption is still eclipsed by 5.2 adoption, to be honest, it feels like doing 1 year bugfix + 1 year security fix is the minimum necessary. By the time we get good adoption of 5.3, it will already be EOL'd. :-/ Users can jump directly to 5.4, too. Yes, I know (Linux) Distributions are conservative and slow and start supporting 5.3 just right now. But well, we have limited resources, only, too. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
Matthew,
Have you seen the new thread and RFC around this?
https://wiki.php.net/rfc/parameter_type_casting_hints
I went with option A, as I see erroring on cast as a more general
problem. So for consistency, I implemented it exactly like normal
explicit casts...
Anthony
On Mon, Mar 5, 2012 at 10:27 AM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On 2012-03-02, Anthony Ferrara ircmax...@gmail.com wrote:
Well, there are a few questions about the implementation:
1. *Which* type casting rules should it follow?
a. Regular cast rules (like $foo = (int) $foo), where it converts
always without error?
b. Internal function cast rules, where it warnings on error and
prevents execution of the function.
c. Current type hinting rules, where if it can't convert cleanly it
E_RECOVERABLE_ERRORS
Personally, I like C the best. Where if it is passed an invalid
value, it attempts to cleanly convert, but errors out if it can't...
But I can see other arguments being made...
(c) seems the most sane option ot me as well.
2. Should (array) be supported? Perhaps. So at that point, foo(array
$bar) would do a strict check, and foo((array) $bar) would attempt
to cast. But my question would be: what would attempt to cast mean?
Should it error out if you pass foo(1)? That's what the internal
function cast rules do. And to me that's more obvious than silently
converting it to foo(array(1))...
Turn this around and look at it from the current state of PHP:
function foo($bar)
{
$bar = (array) $bar;
}
If you pass a value of 1 for $bar, $bar is then converted to array(1).
That's what I'd expect the following to do as well:
function foo((array) $bar)
{
}
It's casting, and clearly different than:
function foo(array $bar)
{
}
which is doing a typehint check.
3. Should references be supported? My feeling is yes, they should.
So if you do foo((array) $bar), it would cast the original value (if
possible) as well.
I personally would expect casting and references to be mutually
exclusive -- if you're casting, you're changing the value type, and I
wouldn't expect a destructive operation like this from passing a value
to a function/method call.
snip
5. What about BC breaks? Well, this entire patch (up to this point)
wouldn't require one. it's only adding the casting functionality
(which is not implemented today), so no problem. Existing code would
still function fine.
This is something that should be highlighted. I've seen a lot of folks
claiming type hinting is viral, and the arguments make no sense to me.
What your patch is offering is _opt_in_ type casting of function/method
arguments. You don't _have_ to write your functions or methods using
them, and for those who do, it should have no side effects on code
calling it.
I would _LOVE_ to see this as part of PHP.
--
Matthew Weier O'Phinney
Project Lead | matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] discussions, about a 5.3 EOL
hi Matthew, On Mon, Mar 5, 2012 at 4:27 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: Considering that 5.3 adoption is still eclipsed by 5.2 adoption, to be honest, it feels like doing 1 year bugfix + 1 year security fix is the minimum necessary. By the time we get good adoption of 5.3, it will already be EOL'd. :-/ Please consider the high level (to do not say almost 100%) of compatibility of PHP 5.4 with 5.3. This is a much lower jump than from 5.2 to 5.3. The same will apply to 5.4+1. With a good communication, and we need you guys from the appsframeworks areas, we will surely reduce the adoption time frame between releases. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: HEADS UP: 5.4 branch is open again
See the other mail from David on Saturday: http://news.php.net/php.internals/58549 On Mon, Mar 5, 2012 at 4:27 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2012-03-02, David Soria Parra d...@php.net wrote: just a heads up. The PHP_5_4 branch is open for commits again. Related: With 5.4.0 out... how soon will the cutover to git occur? -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bugs access request
hi! That one is public :) But yes, you should have access and be part of security@ Cheers, On Mon, Mar 5, 2012 at 4:09 PM, Remi Collet r...@fedoraproject.org wrote: Hi, As PHP (co)maintainer in Fedora, I sometime need to access security bugs which are private. Ex: https://bugs.php.net/bug.php?id=55500 Can I be granted for such access ? Regards, Remi. P.S. I already have an SVN account : remi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bugs access request
This bug report is marked as private. or did that changed just now? On Mon, Mar 5, 2012 at 5:22 PM, Pierre Joye pierre@gmail.com wrote: hi! That one is public :) But yes, you should have access and be part of security@ Cheers, On Mon, Mar 5, 2012 at 4:09 PM, Remi Collet r...@fedoraproject.org wrote: Hi, As PHP (co)maintainer in Fedora, I sometime need to access security bugs which are private. Ex: https://bugs.php.net/bug.php?id=55500 Can I be granted for such access ? Regards, Remi. P.S. I already have an SVN account : remi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Re: [RFC] discussions, about a 5.3 EOL
On 5 March 2012 17:20, Pierre Joye pierre@gmail.com wrote: hi Matthew, On Mon, Mar 5, 2012 at 4:27 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: Considering that 5.3 adoption is still eclipsed by 5.2 adoption, to be honest, it feels like doing 1 year bugfix + 1 year security fix is the minimum necessary. By the time we get good adoption of 5.3, it will already be EOL'd. :-/ Please consider the high level (to do not say almost 100%) of compatibility of PHP 5.4 with 5.3. This is a much lower jump than from 5.2 to 5.3. The same will apply to 5.4+1. This has to be stressed time and again, in order to start changing current perception that upgrading to newer PHP release is a major PITA. b.
Re: [PHP-DEV] Re: [RFC] discussions, about a 5.3 EOL
On Mon, Mar 5, 2012 at 5:41 PM, Bostjan Skufca bost...@a2o.si wrote: This has to be stressed time and again, in order to start changing current perception that upgrading to newer PHP release is a major PITA. I suppose you mean not anymore :) Then go out there to spread the new message and facts! :) -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
Anthony,
I still don't like the null-as-a-default-value solution. I find it
confusing.
I know that something similar appears in class type hinting, but:
1. Class type hinting does not do casting (yet).
2. Apart from null, no other value could be placed anyway. (Even that is a
little bit wrong as null belongs to a different type than the hinted class).
---
I have a different proposal. The argument type hinting/casting should not
be bothered with that at all. Instead, we could expand the type juggling
system a little bit, with the introduction of a special type of casting
that leaves null unchanged. Something like this:
(int?) $x
which should be strictly translated to the following, without any way to
change that behavior by any type casting overload system:
is_null($x) ? null : (int)$x
Examples:
(int?) 13 // 13
(int?) '' // 0
(int?) 0// 0
(int?) null // null
(int?) '342.3Test' // 342
I can think of many real world scenarios that could benefit from this. The
first that comes to my mind is reading from a database, in cases that the
value of null totally different than the value of 0.
$parent_id = (int?) $db['PARENT_ID']; // null and 0 mean different things
here...
A second example is reading from the query string:
$id = (int?) @$_GET['id']; // the error-silencing operator will return
null on error.
Thoughts?
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/5 Anthony Ferrara ircmax...@gmail.com
Matthew,
Have you seen the new thread and RFC around this?
https://wiki.php.net/rfc/parameter_type_casting_hints
I went with option A, as I see erroring on cast as a more general
problem. So for consistency, I implemented it exactly like normal
explicit casts...
Anthony
On Mon, Mar 5, 2012 at 10:27 AM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On 2012-03-02, Anthony Ferrara ircmax...@gmail.com wrote:
Well, there are a few questions about the implementation:
1. *Which* type casting rules should it follow?
a. Regular cast rules (like $foo = (int) $foo), where it converts
always without error?
b. Internal function cast rules, where it warnings on error and
prevents execution of the function.
c. Current type hinting rules, where if it can't convert cleanly it
E_RECOVERABLE_ERRORS
Personally, I like C the best. Where if it is passed an invalid
value, it attempts to cleanly convert, but errors out if it can't...
But I can see other arguments being made...
(c) seems the most sane option ot me as well.
2. Should (array) be supported? Perhaps. So at that point, foo(array
$bar) would do a strict check, and foo((array) $bar) would attempt
to cast. But my question would be: what would attempt to cast mean?
Should it error out if you pass foo(1)? That's what the internal
function cast rules do. And to me that's more obvious than silently
converting it to foo(array(1))...
Turn this around and look at it from the current state of PHP:
function foo($bar)
{
$bar = (array) $bar;
}
If you pass a value of 1 for $bar, $bar is then converted to array(1).
That's what I'd expect the following to do as well:
function foo((array) $bar)
{
}
It's casting, and clearly different than:
function foo(array $bar)
{
}
which is doing a typehint check.
3. Should references be supported? My feeling is yes, they should.
So if you do foo((array) $bar), it would cast the original value (if
possible) as well.
I personally would expect casting and references to be mutually
exclusive -- if you're casting, you're changing the value type, and I
wouldn't expect a destructive operation like this from passing a value
to a function/method call.
snip
5. What about BC breaks? Well, this entire patch (up to this point)
wouldn't require one. it's only adding the casting functionality
(which is not implemented today), so no problem. Existing code would
still function fine.
This is something that should be highlighted. I've seen a lot of folks
claiming type hinting is viral, and the arguments make no sense to me.
What your patch is offering is _opt_in_ type casting of function/method
arguments. You don't _have_ to write your functions or methods using
them, and for those who do, it should have no side effects on code
calling it.
I would _LOVE_ to see this as part of PHP.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] hash / tiger regression in PHP 5.4.0
Le 05/03/2012 17:44, Remi Collet a écrit : Perhaps, the new result is the right one... but I don't find any other tool to check it... Using a simple C program (linked against libmash) Hash: fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39 So the result from php = 5.3.10 seems the right one. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bugs access request
done for bugs. for the sec@ list it can take some more time. Cheers, On Mon, Mar 5, 2012 at 4:09 PM, Remi Collet r...@fedoraproject.org wrote: Hi, As PHP (co)maintainer in Fedora, I sometime need to access security bugs which are private. Ex: https://bugs.php.net/bug.php?id=55500 Can I be granted for such access ? Regards, Remi. P.S. I already have an SVN account : remi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] hash / tiger regression in PHP 5.4.0
Please review https://bugs.php.net/bug.php?id=61291 And attached patch Without the patch 37 PASSED TESTS 0 SKIPPED TESTS 2 FAILED TESTS: mhash_001.phpt mhash_003.phpt With the patch 34 PASSED TESTS 0 SKIPPED TESTS 5 FAILED TESTS: hash_copy_001.phpt hash_file_basic1.phpt hash_hmac_basic.phpt hash_hmac_file_basic.phpt tiger.phpt But it seems the failing tests were introduce after this regression... Perhaps, the new result is the right one... but I don't find any other tool to check it... (it this case mhash_001.phpt and mhash_003.phpt have to be fixed) Regards, Remi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] discussions, about a 5.3 EOL
On 5 March 2012 17:45, Pierre Joye pierre@gmail.com wrote: On Mon, Mar 5, 2012 at 5:41 PM, Bostjan Skufca bost...@a2o.si wrote: This has to be stressed time and again, in order to start changing current perception that upgrading to newer PHP release is a major PITA. I suppose you mean not anymore :) Then go out there to spread the new message and facts! :) Most definitely, but not before I try it out myself :) b.
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
Hi, Lazare
In your examples you are accessing an maybe non-existing array-key.
This will raise an E_NOTICE. See the note below this example:
http://php.net/manual/en/language.types.array.php#example-85
Maybe you also want something like that:
isset($x) ? (is_null($x) ? null : (int)$x) : null
But let's discuss that in a different thread.
Bye
Simon
2012/3/5 Lazare Inepologlou linep...@gmail.com
Anthony,
I still don't like the null-as-a-default-value solution. I find it
confusing.
I know that something similar appears in class type hinting, but:
1. Class type hinting does not do casting (yet).
2. Apart from null, no other value could be placed anyway. (Even that is a
little bit wrong as null belongs to a different type than the hinted
class).
---
I have a different proposal. The argument type hinting/casting should not
be bothered with that at all. Instead, we could expand the type juggling
system a little bit, with the introduction of a special type of casting
that leaves null unchanged. Something like this:
(int?) $x
which should be strictly translated to the following, without any way to
change that behavior by any type casting overload system:
is_null($x) ? null : (int)$x
Examples:
(int?) 13 // 13
(int?) '' // 0
(int?) 0// 0
(int?) null // null
(int?) '342.3Test' // 342
I can think of many real world scenarios that could benefit from this. The
first that comes to my mind is reading from a database, in cases that the
value of null totally different than the value of 0.
$parent_id = (int?) $db['PARENT_ID']; // null and 0 mean different things
here...
A second example is reading from the query string:
$id = (int?) @$_GET['id']; // the error-silencing operator will return
null on error.
Thoughts?
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/5 Anthony Ferrara ircmax...@gmail.com
Matthew,
Have you seen the new thread and RFC around this?
https://wiki.php.net/rfc/parameter_type_casting_hints
I went with option A, as I see erroring on cast as a more general
problem. So for consistency, I implemented it exactly like normal
explicit casts...
Anthony
On Mon, Mar 5, 2012 at 10:27 AM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On 2012-03-02, Anthony Ferrara ircmax...@gmail.com wrote:
Well, there are a few questions about the implementation:
1. *Which* type casting rules should it follow?
a. Regular cast rules (like $foo = (int) $foo), where it converts
always without error?
b. Internal function cast rules, where it warnings on error and
prevents execution of the function.
c. Current type hinting rules, where if it can't convert cleanly it
E_RECOVERABLE_ERRORS
Personally, I like C the best. Where if it is passed an invalid
value, it attempts to cleanly convert, but errors out if it can't...
But I can see other arguments being made...
(c) seems the most sane option ot me as well.
2. Should (array) be supported? Perhaps. So at that point, foo(array
$bar) would do a strict check, and foo((array) $bar) would attempt
to cast. But my question would be: what would attempt to cast mean?
Should it error out if you pass foo(1)? That's what the internal
function cast rules do. And to me that's more obvious than silently
converting it to foo(array(1))...
Turn this around and look at it from the current state of PHP:
function foo($bar)
{
$bar = (array) $bar;
}
If you pass a value of 1 for $bar, $bar is then converted to array(1).
That's what I'd expect the following to do as well:
function foo((array) $bar)
{
}
It's casting, and clearly different than:
function foo(array $bar)
{
}
which is doing a typehint check.
3. Should references be supported? My feeling is yes, they should.
So if you do foo((array) $bar), it would cast the original value (if
possible) as well.
I personally would expect casting and references to be mutually
exclusive -- if you're casting, you're changing the value type, and I
wouldn't expect a destructive operation like this from passing a value
to a function/method call.
snip
5. What about BC breaks? Well, this entire patch (up to this point)
wouldn't require one. it's only adding the casting functionality
(which is not implemented today), so no problem. Existing code would
still function fine.
This is something that should be highlighted. I've seen a lot of folks
claiming type hinting is viral, and the arguments make no sense to me.
What your patch is offering is _opt_in_ type casting of function/method
arguments. You don't _have_ to write your functions or methods using
them, and for those who do, it should have no side effects on code
calling it.
I would _LOVE_ to see this as part of PHP.
--
Matthew
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
In your examples you are accessing an maybe non-existing array-key
Yes, this is why I used the error silencing (@) operator. But anyway, it is
irrelevant to the whole proposal.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/5 Simon Schick simonsimc...@googlemail.com
Hi, Lazare
In your examples you are accessing an maybe non-existing array-key.
This will raise an E_NOTICE. See the note below this example:
http://php.net/manual/en/language.types.array.php#example-85
Maybe you also want something like that:
isset($x) ? (is_null($x) ? null : (int)$x) : null
But let's discuss that in a different thread.
Bye
Simon
2012/3/5 Lazare Inepologlou linep...@gmail.com
Anthony,
I still don't like the null-as-a-default-value solution. I find it
confusing.
I know that something similar appears in class type hinting, but:
1. Class type hinting does not do casting (yet).
2. Apart from null, no other value could be placed anyway. (Even that is a
little bit wrong as null belongs to a different type than the hinted
class).
---
I have a different proposal. The argument type hinting/casting should not
be bothered with that at all. Instead, we could expand the type juggling
system a little bit, with the introduction of a special type of casting
that leaves null unchanged. Something like this:
(int?) $x
which should be strictly translated to the following, without any way to
change that behavior by any type casting overload system:
is_null($x) ? null : (int)$x
Examples:
(int?) 13 // 13
(int?) '' // 0
(int?) 0// 0
(int?) null // null
(int?) '342.3Test' // 342
I can think of many real world scenarios that could benefit from this. The
first that comes to my mind is reading from a database, in cases that the
value of null totally different than the value of 0.
$parent_id = (int?) $db['PARENT_ID']; // null and 0 mean different things
here...
A second example is reading from the query string:
$id = (int?) @$_GET['id']; // the error-silencing operator will return
null on error.
Thoughts?
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/5 Anthony Ferrara ircmax...@gmail.com
Matthew,
Have you seen the new thread and RFC around this?
https://wiki.php.net/rfc/parameter_type_casting_hints
I went with option A, as I see erroring on cast as a more general
problem. So for consistency, I implemented it exactly like normal
explicit casts...
Anthony
On Mon, Mar 5, 2012 at 10:27 AM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On 2012-03-02, Anthony Ferrara ircmax...@gmail.com wrote:
Well, there are a few questions about the implementation:
1. *Which* type casting rules should it follow?
a. Regular cast rules (like $foo = (int) $foo), where it converts
always without error?
b. Internal function cast rules, where it warnings on error and
prevents execution of the function.
c. Current type hinting rules, where if it can't convert cleanly it
E_RECOVERABLE_ERRORS
Personally, I like C the best. Where if it is passed an invalid
value, it attempts to cleanly convert, but errors out if it can't...
But I can see other arguments being made...
(c) seems the most sane option ot me as well.
2. Should (array) be supported? Perhaps. So at that point,
foo(array
$bar) would do a strict check, and foo((array) $bar) would attempt
to cast. But my question would be: what would attempt to cast mean?
Should it error out if you pass foo(1)? That's what the internal
function cast rules do. And to me that's more obvious than silently
converting it to foo(array(1))...
Turn this around and look at it from the current state of PHP:
function foo($bar)
{
$bar = (array) $bar;
}
If you pass a value of 1 for $bar, $bar is then converted to array(1).
That's what I'd expect the following to do as well:
function foo((array) $bar)
{
}
It's casting, and clearly different than:
function foo(array $bar)
{
}
which is doing a typehint check.
3. Should references be supported? My feeling is yes, they should.
So if you do foo((array) $bar), it would cast the original value (if
possible) as well.
I personally would expect casting and references to be mutually
exclusive -- if you're casting, you're changing the value type, and I
wouldn't expect a destructive operation like this from passing a value
to a function/method call.
snip
5. What about BC breaks? Well, this entire patch (up to this point)
wouldn't require one. it's only adding the casting functionality
(which is not implemented today), so no problem. Existing code would
still function fine.
This is something that should be highlighted. I've seen a lot of folks
claiming type hinting is viral, and the arguments make no sense to me.
What your patch
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
Hi, Lazare
Sorry, I've only looked at your first array-example :)
Bye
Simon
2012/3/5 Lazare Inepologlou linep...@gmail.com
In your examples you are accessing an maybe non-existing array-key
Yes, this is why I used the error silencing (@) operator. But anyway, it
is irrelevant to the whole proposal.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/5 Simon Schick simonsimc...@googlemail.com
Hi, Lazare
In your examples you are accessing an maybe non-existing array-key.
This will raise an E_NOTICE. See the note below this example:
http://php.net/manual/en/language.types.array.php#example-85
Maybe you also want something like that:
isset($x) ? (is_null($x) ? null : (int)$x) : null
But let's discuss that in a different thread.
Bye
Simon
2012/3/5 Lazare Inepologlou linep...@gmail.com
Anthony,
I still don't like the null-as-a-default-value solution. I find it
confusing.
I know that something similar appears in class type hinting, but:
1. Class type hinting does not do casting (yet).
2. Apart from null, no other value could be placed anyway. (Even that is
a
little bit wrong as null belongs to a different type than the hinted
class).
---
I have a different proposal. The argument type hinting/casting should not
be bothered with that at all. Instead, we could expand the type juggling
system a little bit, with the introduction of a special type of casting
that leaves null unchanged. Something like this:
(int?) $x
which should be strictly translated to the following, without any way to
change that behavior by any type casting overload system:
is_null($x) ? null : (int)$x
Examples:
(int?) 13 // 13
(int?) '' // 0
(int?) 0// 0
(int?) null // null
(int?) '342.3Test' // 342
I can think of many real world scenarios that could benefit from this.
The
first that comes to my mind is reading from a database, in cases that the
value of null totally different than the value of 0.
$parent_id = (int?) $db['PARENT_ID']; // null and 0 mean different
things
here...
A second example is reading from the query string:
$id = (int?) @$_GET['id']; // the error-silencing operator will return
null on error.
Thoughts?
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/5 Anthony Ferrara ircmax...@gmail.com
Matthew,
Have you seen the new thread and RFC around this?
https://wiki.php.net/rfc/parameter_type_casting_hints
I went with option A, as I see erroring on cast as a more general
problem. So for consistency, I implemented it exactly like normal
explicit casts...
Anthony
On Mon, Mar 5, 2012 at 10:27 AM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On 2012-03-02, Anthony Ferrara ircmax...@gmail.com wrote:
Well, there are a few questions about the implementation:
1. *Which* type casting rules should it follow?
a. Regular cast rules (like $foo = (int) $foo), where it converts
always without error?
b. Internal function cast rules, where it warnings on error and
prevents execution of the function.
c. Current type hinting rules, where if it can't convert cleanly it
E_RECOVERABLE_ERRORS
Personally, I like C the best. Where if it is passed an invalid
value, it attempts to cleanly convert, but errors out if it can't...
But I can see other arguments being made...
(c) seems the most sane option ot me as well.
2. Should (array) be supported? Perhaps. So at that point,
foo(array
$bar) would do a strict check, and foo((array) $bar) would attempt
to cast. But my question would be: what would attempt to cast mean?
Should it error out if you pass foo(1)? That's what the internal
function cast rules do. And to me that's more obvious than silently
converting it to foo(array(1))...
Turn this around and look at it from the current state of PHP:
function foo($bar)
{
$bar = (array) $bar;
}
If you pass a value of 1 for $bar, $bar is then converted to
array(1).
That's what I'd expect the following to do as well:
function foo((array) $bar)
{
}
It's casting, and clearly different than:
function foo(array $bar)
{
}
which is doing a typehint check.
3. Should references be supported? My feeling is yes, they should.
So if you do foo((array) $bar), it would cast the original value
(if
possible) as well.
I personally would expect casting and references to be mutually
exclusive -- if you're casting, you're changing the value type, and I
wouldn't expect a destructive operation like this from passing a
value
to a function/method call.
snip
5. What about BC breaks? Well, this entire patch (up to this point)
wouldn't require one. it's only adding the casting functionality
(which is not implemented today), so no problem. Existing code
would
still function fine.
This is something that
[PHP-DEV] Re: [VOTE] APXS LoadModule Option in configure
FYI- Voting will be closed at 2 PM (PST) tomorrow. --Kris On Thu, Mar 1, 2012 at 1:04 PM, Kris Craig kris.cr...@gmail.com wrote: Just a friendly reminder to vote on this if you haven't already. 5 people have voted on it thus far but I'd like to have at least twice that by the time voting closes. You can read the RFC and vote on it at: https://wiki.php.net/rfc/apxs-loadmodule Thanks! --Kris On Tue, Feb 28, 2012 at 12:19 PM, Kris Craig kris.cr...@gmail.com wrote: Hi all, It looks like we've reached a consensus on this, so absent any objections, I went ahead and moved this to the voting phase. If you're eligible to vote on RFC's, please navigate to the RFC and cast your vote now: https://wiki.php.net/rfc/apxs-loadmodule In case you weren't following the previous thread, this is a very low-impact RFC that will add a new, optional switch to the configure script. This switch, if specified, would tell APXS (which already has this functionality built-in) not to write the LoadModule line to httpd.conf when make install is performed. This is a feature that has been requested for some time and would allow people with manually-built PHP installs to isolate their mod_php hooks in a separate php.conf file without having to manually edit httpd.conf whenever a new build is performed. If this optional switch is not specified, the configure script will behave exactly as it does now. As such, this RFC will *not* alter configure's existing behavior unless you explicitly include this new switch. Please let me know if you have any last-minute questions. Otherwise, happy voting! Thanks! --Kris
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
Hi Lazare, I'm a bit divided on your proposal. On one hand I kind of like the simplicity of the syntax and the basic idea behind it: (int?) $x which should be strictly translated to the following, without any way to change that behavior by any type casting overload system: is_null($x) ? null : (int)$x But on the other hand, I'm not sure you should mix type casting and the short if syntax (which is clearly what inspired the question mark there). This sort of makes me think you're really turning an (int) type casting, into more of a (mixed) type casting... I don't really like that! :) Therefore I'm divided into thinking this is a cool idea, or if I'd get so confused about this I would use it as much as the short if syntax: $var = @$_GET['var'] ?: 'default'; (Which is never, btw!) How about allowing *several entries* per type cast (since spaces are allowed inside casts anyway, but could also be a semicolon or something): $int_or_null = (int unset) $x; This could be usefull for other instances as (string null) or (bool null) as well... Your thoughts? Best regards, ~ Daniel Macedo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
This could be usefull for other instances as (string null) or (bool null) as well... Your thoughts? Typo! The examples should read (string unset) and (bool unset) BTW: Order would equal what is type casted OR simply accepted! ~ Daniel Macedo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
Hi Daniel, No, it is not inspired from the short ternary operator. It's a rather common conversion. C# has a similar notion of nullable types (with totally different mechanics however). By the way, in this particular area PHP's type system is more sound than that of C#, because null is not just a special value of any type but it is a value of a separate null type. Kudos to the original designers for this choice. Your proposal for (int unset) is not very far away from what I propose. In PHPDoc, and in many IDEs, there are often mixed types like these: int|string int|null string|bool|null bool|null DateTime|null ... Of all different combinations, the ones between a type and null are very usual. So, I propose int? as a shortcut for int|null. In that sense, it is totally equivalent to int unset that you say. Personally, I find unset not proper for this case, because it is not going to unset anything that is not already null. BTW: Order would equal what is type casted OR simply accepted! Do you have any examples where this could be useful? Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/5 Daniel Macedo admac...@gmail.com This could be usefull for other instances as (string null) or (bool null) as well... Your thoughts? Typo! The examples should read (string unset) and (bool unset) BTW: Order would equal what is type casted OR simply accepted! ~ Daniel Macedo
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On 2012-03-02, Sebastian Bergmann sebast...@php.net wrote: On 03/02/2012 07:34 AM, Pierre Joye wrote: https://wiki.php.net/rfc/php53eol I discussed with Arne Blankerts and Stefan Priebsch over breakfast today and Stefan had an interesting idea: why not announce (now) that PHP 5.3 will go into EOL a year after PHP 5.5 comes out? * Now until PHP 5.5 comes out: bug and security fixes for PHP 5.3 * From the release of PHP 5.5: security fixes for PHP 5.3 for a year Ideally, PHP 5.5 would be out in a year from now, so it would come down to one year of bug and security fixes and one year of security fixes only. Makes sense to me. +1. Since so many distros and ISPs tend to adopt late, this would keep them, and their users, covered for a reasonable time period, allowing for a cleaner migration path. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
Sorry, I used unset in the same way type casting works, not as in
unset() ... Common gotcha: http://php.net/unset#example-4824
Here's how the manual refers to it:
http://php.net/type-juggling
(int), (integer) - cast to integer
(bool), (boolean) - cast to boolean
(float), (double), (real) - cast to float
(string) - cast to string
(array) - cast to array
(object) - cast to object
(unset) - cast to NULL (PHP 5)
I understood what you meant but I'd rather have it be more verbose but
more clear as well.
I read your idea, as Cast to int, or accept NULL I rather
use/read that as (int unset) rather than (int?)
BTW: Order would equal what is type casted OR simply accepted!
Do you have any examples where this could be useful?
The same example you gave of data that comes from a database NULL
would be retained, else it's type casted to int.
// Cast to int, accept null
(int unset) 13 // 13
(int unset) ''// 0
(int unset) 0 // 0
(int unset) NULL // NULL
(int unset) '342.3Test' // 342
My view is, if you use the naming as it's currently used in type
casting, you also get additional functionality:
// Cast to string, accept bool
(string bool) 'test' // 'test'
(string bool) 123 // '123'
(string bool) TRUE // TRUE
(string bool) FALSE // FALSE
(string bool) NULL // ''
// Cast to string, accept array
(string array) 'test' // 'test'
(string array) 123 // '123'
(string array) TRUE // '1'
(string array) array(1, 2, 3) // array(3) { [0]= int(1) [1]=
int(2) [2]= int(3) }
I find this way more useful/complete/readable than what you proposed.
Best regards,
~ Daniel Macedo
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On Mon, Mar 5, 2012 at 9:53 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: +1. Votes are for later. Since so many distros and ISPs tend to adopt late, this would keep them, and their users, covered for a reasonable time period, allowing for a cleaner migration path. There is a clear migration path defined now for all releases beginning from 5.4. The discussion here is about 5.3 only. Please read all posts or replies, it helps to get the whole idea and avoid repetitive arguing :) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] '?=' with PHP5.3.10
On Mon, Mar 5, 2012 at 5:50 AM, Lester Caine les...@lsces.co.uk wrote: OK what changed in the automatic updates from PHP5.3.9 to 5.3.10 that stops '?=' working when it was working previously? I do not recall the state of short_open_tag changing but was that 'defaulted' to off when previously it was on? I had thought that '?=' was discussed and had been left alone, but now I'm told that is only on PHP5.4.0 What's the value of short_open_tag? If disabled, does the host's setup allow you to set its value? Something broke sites without any warning and it would have been nice to be told by that ISP that they were updating PHP anyway :( -- Lester Caine - G8HFL -
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On 2012-03-05, Pierre Joye pierre@gmail.com wrote: On Mon, Mar 5, 2012 at 9:53 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: +1. Votes are for later. This was an indication of being in favor of the proposal, no more, no less. Since so many distros and ISPs tend to adopt late, this would keep them, and their users, covered for a reasonable time period, allowing for a cleaner migration path. There is a clear migration path defined now for all releases beginning from 5.4. The discussion here is about 5.3 only. Please read all posts or replies, it helps to get the whole idea and avoid repetitive arguing :) I did, actually. I still agree with Sebastian's proposal. While the PHP group may want to push for faster adoption, the pattern I've observed over and over is that ISPs and distributions -- particularly those with LTS offerings -- tend to adopt a minor version only when the new minor version supplanting it has been released. Does it make sense? No. Is it what happens? Yes. As such, I think it makes a lot of sense to base the lifetime of 5.3 based on when 5.4 is released. For the record, it's the path we're taking with ZF as well -- lifetime for the last minor release of ZF v1 will be determined by when ZF2-stable is released. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] '?=' with PHP5.3.10
Personally, I HATE short_open_tab. It has no value-- *except* that, unfortunately, it's still widely used in many apps and even some frameworks TTBOMK. So, as worthless as it is, removing it completely would render these apps inoperable. Leaving it turned-off by default is a given I think, as at very least people should be discouraged from using them. I also wouldn't be opposed to the idea of deprecating them, which would allow these apps time to fix their code accordingly. I can't address the original question about its current status; I just wanted to weight in on the what's the value question. Answer: None, except that too many people are still using them. =) --Kris On Mon, Mar 5, 2012 at 2:48 PM, Galen Wright-Watson ww.ga...@gmail.comwrote: On Mon, Mar 5, 2012 at 5:50 AM, Lester Caine les...@lsces.co.uk wrote: OK what changed in the automatic updates from PHP5.3.9 to 5.3.10 that stops '?=' working when it was working previously? I do not recall the state of short_open_tag changing but was that 'defaulted' to off when previously it was on? I had thought that '?=' was discussed and had been left alone, but now I'm told that is only on PHP5.4.0 What's the value of short_open_tag? If disabled, does the host's setup allow you to set its value? Something broke sites without any warning and it would have been nice to be told by that ISP that they were updating PHP anyway :( -- Lester Caine - G8HFL -
Re: [PHP-DEV] '?=' with PHP5.3.10
Err *short_open_tag On Mon, Mar 5, 2012 at 3:04 PM, Kris Craig kris.cr...@gmail.com wrote: Personally, I HATE short_open_tab. It has no value-- *except* that, unfortunately, it's still widely used in many apps and even some frameworks TTBOMK. So, as worthless as it is, removing it completely would render these apps inoperable. Leaving it turned-off by default is a given I think, as at very least people should be discouraged from using them. I also wouldn't be opposed to the idea of deprecating them, which would allow these apps time to fix their code accordingly. I can't address the original question about its current status; I just wanted to weight in on the what's the value question. Answer: None, except that too many people are still using them. =) --Kris On Mon, Mar 5, 2012 at 2:48 PM, Galen Wright-Watson ww.ga...@gmail.comwrote: On Mon, Mar 5, 2012 at 5:50 AM, Lester Caine les...@lsces.co.uk wrote: OK what changed in the automatic updates from PHP5.3.9 to 5.3.10 that stops '?=' working when it was working previously? I do not recall the state of short_open_tag changing but was that 'defaulted' to off when previously it was on? I had thought that '?=' was discussed and had been left alone, but now I'm told that is only on PHP5.4.0 What's the value of short_open_tag? If disabled, does the host's setup allow you to set its value? Something broke sites without any warning and it would have been nice to be told by that ISP that they were updating PHP anyway :( -- Lester Caine - G8HFL -
Re: [PHP-DEV] '?=' with PHP5.3.10
Galen Wright-Watson wrote: OK what changed in the automatic updates from PHP5.3.9 to 5.3.10 that stops '?=' working when it was working previously? I do not recall the state of short_open_tag changing but was that 'defaulted' to off when previously it was on? I had thought that'?=' was discussed and had been left alone, but now I'm told that is only on PHP5.4.0 What's the value of short_open_tag? If disabled, does the host's setup allow you to set its value? If you read the other posts you will see the answers ;) The ISP hosting these sites has not got back to me yet, but it would seem that when they updated from 5.3.9 to 5.3.10 they also switched off short_open_tag when previously it had been on. It's a little annoying that I've had to rework these sites when I WILL put it back again once I can move them to a site where it does not matter. I prefer the shorthand as the longhand makes the code a lot more difficult to read. Something broke sites without any warning and it would have been nice to be told by that ISP that they were updating PHP anyway:( This is the sort of insidious little change that gets annoying when people don't understand the consequences of changing it. I wonder how many more people have been affected just on this ISP ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] '?=' with PHP5.3.10
Kris Craig wrote: Personally, I HATE short_open_tab. It has no value--*except* that, unfortunately, it's still widely used in many apps and even some frameworks TTBOMK. So, as worthless as it is, removing it completely would render these apps inoperable. Leaving it turned-off by default is a given I think, as at very least people should be discouraged from using them. I also wouldn't be opposed to the idea of deprecating them, which would allow these apps time to fix their code accordingly. While I think that we SHOULD just have stuck up for '?' when the 'problem' arose I'm resigned to having to use ?php nowadays and it's not a problem anyway when most of the html work is done in smarty templates, but '?=' is still perfectly valid, and makes a lot more sense to keep - which it HAS been in 5.4 - It's just the tie-in with short_open_tag that has caused the agro in 5.3.10 with people following the 'recommendation' to switch it off without even advising they are doing so or understanding what else will be broken :( When one has customers ringing up asking why their sites are down and YOU have not changed anything, finding out why took a little while this morning ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] '?=' with PHP5.3.10
On Mon, Mar 5, 2012 at 6:04 PM, Kris Craig kris.cr...@gmail.com wrote: Personally, I HATE short_open_tab. It has no value-- *except* that, unfortunately, it's still widely used in many apps and even some frameworks TTBOMK. I personally like it and find value in its inclusion :) Adam
Re: [PHP-DEV] '?=' with PHP5.3.10
I understand the problem with ? and XML, it was just ?= that seemed safe enough to me. Glad it's standard in 5.4. On Mon, Mar 5, 2012 at 6:21 PM, Adam Jon Richardson adamj...@gmail.com wrote: On Mon, Mar 5, 2012 at 6:04 PM, Kris Craig kris.cr...@gmail.com wrote: Personally, I HATE short_open_tab. It has no value-- *except* that, unfortunately, it's still widely used in many apps and even some frameworks TTBOMK. I personally like it and find value in its inclusion :) Adam -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] '?=' with PHP5.3.10
Certainly. I don't believe this is about inclusion any more than creating a function called ech as an alias for echo would be. The ? tag, as you all know, creates problems when working with XML. Furthermore, I've never understood the it's easier to read argument since I've found it to be exactly the opposite. The ? as opposed to ?php, at least for me, makes it more difficult to at a glance see where the PHP code begins (i.e. it's smaller and more ambiguous). Also, since many hosts disable it by default, getting apps/frameworks that use them working can be an added pain. On the other hand, considering how verbose many of our function names are, I've never understood why the extra 3 characters (or 2 now that it's ?=) is such a burden that we have to deal with all the above annoyances instead. Like I said, other than the fraction of a second it takes to type php, I really don't see any value in this. Let's try this from a financial angle. After all, time is money, right? So let's assume that, on average, it takes you one half of one second to type the string php. Let's also assume that the average salary for a PHP developer (source: simplyhired.com) in the United States is $56,000/yr. Rounding-up, that comes out to $27/hr. So, how much is that one half of one second burden costing this unfortunate, superbly average PHP developer? 27 / (60 ^ 2) / 2 == $0.00375. In other words, roughly 1/3 of one cent. So yeah, I guess I stand corrected. The short_open_tag isn't worthless. It's worth a third of a penny. My bad. ;P --Kris P.S. Seriously, if you like short_open_tags, it's really not a big deal for me. I just don't see any value in them, myself. On Mon, Mar 5, 2012 at 3:28 PM, Tom Boutell t...@punkave.com wrote: I understand the problem with ? and XML, it was just ?= that seemed safe enough to me. Glad it's standard in 5.4. On Mon, Mar 5, 2012 at 6:21 PM, Adam Jon Richardson adamj...@gmail.com wrote: On Mon, Mar 5, 2012 at 6:04 PM, Kris Craig kris.cr...@gmail.com wrote: Personally, I HATE short_open_tab. It has no value-- *except* that, unfortunately, it's still widely used in many apps and even some frameworks TTBOMK. I personally like it and find value in its inclusion :) Adam -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com
Re: [PHP-DEV] '?=' with PHP5.3.10
Am 06.03.2012 01:03, schrieb Kris Craig: I've never understood the it's easier to read argument since I've found it to be exactly the opposite. The ? as opposed to ?php, at least for me, makes it more difficult to at a glance see where the PHP code begins if you hvae a usebale editor ?=$whatever? would become different colors only in notepad or on the shell you would not see php-code but who does develop this way these days? signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] '?=' with PHP5.3.10
On Windows (where I generally do most of my scripting grunt work), I typically use Notepad++ and it highlights ?php just fine. --Kris On Mon, Mar 5, 2012 at 4:11 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 06.03.2012 01:03, schrieb Kris Craig: I've never understood the it's easier to read argument since I've found it to be exactly the opposite. The ? as opposed to ?php, at least for me, makes it more difficult to at a glance see where the PHP code begins if you hvae a usebale editor ?=$whatever? would become different colors only in notepad or on the shell you would not see php-code but who does develop this way these days?
Re: [PHP-DEV] '?=' with PHP5.3.10
On Mon, Mar 5, 2012 at 3:08 PM, Lester Caine les...@lsces.co.uk wrote: Galen Wright-Watson wrote: OK what changed in the automatic updates from PHP5.3.9 to 5.3.10 that stops '?=' working when it was working previously? I do not recall the state of short_open_tag changing but was that 'defaulted' to off when previously it was on? I had thought that'?=' was discussed and had been left alone, but now I'm told that is only on PHP5.4.0 What's the value of short_open_tag? If disabled, does the host's setup allow you to set its value? If you read the other posts you will see the answers ;) Only you can answer these questions, as only someone on the host can check the default configuration and what can be configured. The others on this list can only state how PHP should behave (which is what they posted). For all we know, your host is running a custom patch. Hopefully, you can simply enable short_open_tags in .htaccess, so that code edits aren't required.
[PHP-DEV] Scalar Type Hinting
Hello, I came across some info on the web that states that scalar type hinting was added to the PHP trunk but it did not make it's way into 5.4 because of objections from the community. Will it ever make it's way into 5.5? I know PHP is considered to be a weak typed language but it should also be about freedom. Freedom for a PHP developer to choose to use scalar type hinting whenever he/she sees the need. Best regards, __ Raymond
Re: [PHP-DEV] Scalar Type Hinting
Wow no offense, but your timing is terrible, Raymond! We've been going back and forth on this for the past couple weeks now, though the discussion has quieted for the moment. I would suggest you go through some of the recent posts on Internals. Right now there basically is no solid consensus on this issue, though some of us have been working to change that. But as it stands now, I'm not aware of any plans to introduce expanded typing of any kind in the foreseeable future. And even if we did, I highly doubt it would happen before PHP 6. --Kris On Mon, Mar 5, 2012 at 6:20 PM, Raymond Irving xwis...@gmail.com wrote: Hello, I came across some info on the web that states that scalar type hinting was added to the PHP trunk but it did not make it's way into 5.4 because of objections from the community. Will it ever make it's way into 5.5? I know PHP is considered to be a weak typed language but it should also be about freedom. Freedom for a PHP developer to choose to use scalar type hinting whenever he/she sees the need. Best regards, __ Raymond
Re: [PHP-DEV] '?=' with PHP5.3.10
On Mon, Mar 5, 2012 at 7:03 PM, Kris Craig kris.cr...@gmail.com wrote: Certainly. I don't believe this is about inclusion any more than creating a function called ech as an alias for echo would be. The ? tag, as you all know, creates problems when working with XML. Furthermore, I've never understood the it's easier to read argument since I've found it to be exactly the opposite. The ? as opposed to ?php, at least for me, makes it more difficult to at a glance see where the PHP code begins (i.e. it's smaller and more ambiguous). Also, since many hosts disable it by default, getting apps/frameworks that use them working can be an added pain. On the other hand, considering how verbose many of our function names are, I've never understood why the extra 3 characters (or 2 now that it's ?=) is such a burden that we have to deal with all the above annoyances instead. Like I said, other than the fraction of a second it takes to type php, I really don't see any value in this. The tag ?= isn't a short version for ?php or ?. The ?= allows you to echo output, so these two examples are equivalent: ?php echo $var; ? ?= $var ? http://www.php.net/manual/en/ini.core.php#ini.short-open-tag Before 5.4, turning off short tags turned off the shorthand echo tag, too. The value I referenced was regarding the echo form of the tag (?=), the form of the tag Lester was troubleshooting. With 5.4, this will no longer be a concern, as the echo form will always be available. Adam
Re: [PHP-DEV] '?=' with PHP5.3.10
Woops ok, you're right about that. So then, the short open tag is still just ?? (that last question mark is punctuation ;P) --Kris On Mon, Mar 5, 2012 at 7:44 PM, Adam Jon Richardson adamj...@gmail.comwrote: On Mon, Mar 5, 2012 at 7:03 PM, Kris Craig kris.cr...@gmail.com wrote: Certainly. I don't believe this is about inclusion any more than creating a function called ech as an alias for echo would be. The ? tag, as you all know, creates problems when working with XML. Furthermore, I've never understood the it's easier to read argument since I've found it to be exactly the opposite. The ? as opposed to ?php, at least for me, makes it more difficult to at a glance see where the PHP code begins (i.e. it's smaller and more ambiguous). Also, since many hosts disable it by default, getting apps/frameworks that use them working can be an added pain. On the other hand, considering how verbose many of our function names are, I've never understood why the extra 3 characters (or 2 now that it's ?=) is such a burden that we have to deal with all the above annoyances instead. Like I said, other than the fraction of a second it takes to type php, I really don't see any value in this. The tag ?= isn't a short version for ?php or ?. The ?= allows you to echo output, so these two examples are equivalent: ?php echo $var; ? ?= $var ? http://www.php.net/manual/en/ini.core.php#ini.short-open-tag Before 5.4, turning off short tags turned off the shorthand echo tag, too. The value I referenced was regarding the echo form of the tag (?=), the form of the tag Lester was troubleshooting. With 5.4, this will no longer be a concern, as the echo form will always be available. Adam
[PHP-DEV] Providing sandboxed versions of include and require language constructs
Plugins are a big deal (see
http://oneofmanyworlds.blogspot.in/2012/03/difficult-decision.html for a
recent example.) In this era of mashups and breakneck innovation,
developers must rely on vast amounts of code they've never seen, let alone
audited. Wordpress, Drupal, and many other tools developed in PHP make
plugin development easy and extremely powerful. While these tools
constantly work to improve security (and, at least relatively, do a solid
job most of the time), there remains significant challenges due to globally
accessible functions that allow manipulation of the environment (files,
DB's, networking, etc.) Any plugin can use these global functions to work
around the security restrictions imposed by the framework, library, or CMS.
While code audits can locate the offending scripts, this is a challenging
task, both in terms of time AND abilities. Languages and/or environments
that can mitigate these issues for the developer, while far from fool
proof, do offer real value on the security front. Lua provides the ability
for developers to limit the functions available in the current environment:
http://lua-users.org/wiki/SandBoxes
PHP does have an extension that offers several forms of sandboxing: runkit.
However, it's often not available in shared host environments.
The include (and require) construct is the front door for any plugin code.
What if PHP offered functions that implemented sandboxed versions of the
include and require language constructs (e.g.,
included_restricted('file/path', $functions = array('file',
'file_get_contents')))? Functional specs could include:
1) Internal functions seen as universally safe would by default be allowed
(e.g, str_replace(), array_pop(), etc.)
2) Unsafe internal functions would have to be explicitly declared (e.g.,
file(), stream_*, etc.)
3) Any includes or requires within the sandboxed code would be forced to
meet the same restrictions. (tricky)
4) Code containing unsafe functions not included in the whitelist would
raise an error.
There would be a performance hit for code that actually used the sandboxed
functions to include scripts, but for many applications, I suspect this
would be worth the hit. Security is becoming more important by the day
(just ask github: http://homakov.blogspot.com/2012/03/how-to.html#), and
empowering the developer with tools to enforce greater restrictions on the
ever-growing heaps of unaudited code seems wise.
Thoughts?
Adam
