Re: [PHP-DEV] Scalar Type Intentions
This is a potential concern if the aliases for scalar were included (bool, int, float, string), as Anthony mentioned, although merely implementing the first part of the proposal (scalar type hinting) wouldn't cause any trouble. Yes, exactly. I was only talking about this specific aspect. Otherwise, it is a fine and welcome proposal. I would love to have type-checking as long as it does not close the door to type-juggling some time in the future. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/1 Adam Jon Richardson adamj...@gmail.com On Thu, Mar 1, 2012 at 10:36 AM, Lazare Inepologlou linep...@gmail.comwrote: Of note, the scalar type hinting I've outlined does not automatically perform casts... Thank you for your answer. Maybe, this exact fact is what I don't like about your suggestion. Please read the following RFC, where Lukas Smith and Zeev Suraski explain very well why strict type checking without auto-casting is a not a great idea. Of course it is just an RFC, but I find it quite correct. https://wiki.php.net/rfc/typecheckingstrictandweak I believe we interpret that RFC differently. Those who wrote it can correct me if I'm in error. The RFC is a very interesting approach to providing some form of type hinting for scalar parameters in functions and methods. I liked the RFC, but I understand some of the concerns that come up when discussing something like it. First, I believe that when the RFC contrasts strict and weak typing, it would be fair to say this is what many others would describe as strong vs weak typing: http://en.wikipedia.org/wiki/Type_system#Strong_and_weak_typing The RFC makes the case that strict typing is is an alien concept to PHP, and that it goes against PHP's type system, while pointing out other issues. The RFC makes it clear that trying to map strict typing onto PHP is problematic, and on this issue I tend to agree. The RFC then offers three options for weak type hinting. One main point I'd bring out for all of the options is that they all strengthen the typing (that is, while still a weak type system, it moves slightly towards the strong side of the continuum) beyond PHP's default type juggling rules because some type of error would be raised in the event of data loss. So, their proposal outlines weak forms of type hinting for scalars, and mine is similar but weaker, as there is no auto casting, there are no new errors raised for data loss, and all checks are against the generic scalar type (whether with or without the aliases.) This brings my proposal even closer to the fundamental typing characteristics of PHP, whilst protecting against the potential errors pointed out in my earlier examples. My concern is that if your suggestion is adopted (as it is, without auto-casting) then an eventual introduction of auto-casting will be impossible without breaking BC. This is a potential concern if the aliases for scalar were included (bool, int, float, string), as Anthony mentioned, although merely implementing the first part of the proposal (scalar type hinting) wouldn't cause any trouble. However, the more a proposal moves away from PHP's current typing conventions, the less likely it is to be considered, let alone approved. I'm not confident a more aggressive proposal (e.g., auto-casting with checks for information loss) would be approved any time soon. PHP is one of the most practically oriented programming languages I'm aware of, and my practicalities just want to put forward ideas that improve some issues AND that might actually get done :) Again, thanks for the commentary, Lazare. Adam
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Hi, Kris
I have to confirm that that's not really what I wanted.
But many people were now talking about type-hint to scalar, but that was
maybe in another thread in this list :)
To get more to the point what were discussing about want:
Why not always (at least try) to transform the data?
In PHP 5.4 they've introduced quite a lot of new stuff around exactly that:
* Changed silent conversion of array to string to produce a notice.
* Changed silent casting of null/''/false into an Object when adding a
property into a warning.
I would suppose to add a type-hint for the following types:
* Boolean
* integer
* float
* string
Here's the last state what I thought about these type-hints ...
Both of the given examples here should give the same result:
foo(boolean $b, integer $i, float $f, string $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;
// your code
}
If you view it from that site - you can't get an array to do what you can
do with an object. Therefore I think it's quite OK to break the script
there, but here, as you can transform the values, I'd (at least try to)
transform the given data into the expected format.
The only thing I'm quite unsure about - should we trigger a E_WARNING or
E_NOTICE if we have data-loose in this transformation? Just let it pass as
it's transformable, but trigger some error ...
If you want to get a warning or notice in the function *foo2* then open a
new thread, as I think that should not be discussed here. It affects much
more than just the function-call.
p.s. What about adding another type-hint for resources?
That's something we could check by *is_resource()* and it would make sense
(at least to me).
Bye
Simon
2012/3/2 Kris Craig kris.cr...@gmail.com
I agree with what John said. Limiting the scope to scalars, while having
some advantages, probably wouldn't pass the usefulness test for most
people.
--Kris
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.com
wrote:
From: Richard Lynch [mailto:c...@l-i-e.com]
On Thu, March 1, 2012 2:38 am, John Crenshaw wrote:
You might consider those scripts poor programming practice. We all
do.
But PHP is the language of the unwashed masses, and that was, and
is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the
way.
And in 20 minutes I can hack into that application 20 different ways.
This isn't really PHP's fault...or is it? By deliberately catering to
the lowest possible denominator is it possible that PHP itself
contributes to the proliferation of wildly insecure web sites? I do
understand the unwashed masses argument, and yet, the security geek
in me sometimes questions how good this is.
(Before someone flames me, I'm not really saying that we should scrap
any foundational principles or tell basic users to go hang
themselves.
This is mostly philosophical musing.)
We make concerted efforts to educate scripters, by posting the same
thing in all our blogs.
Even if all they understand is Don't do this! it's good enough for
most of them.
Other times the decision was made to just deprecate a feature and
provide a migration path,
if suitable, but spread out over major
releases:
PHP x.0: Feature is bad, but there
PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP)
[This is the bit
where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature
is
just gone.
People who completely ignore docs or don't upgrade remain vulnerable,
but there's not much
you can do without making life miserable for a bazillion developers.
No, you've misunderstood. The average new not-really-a-developer has no
concept of security. Every SQL query they write is vulnerable to
injection.
Every echo exposes their site to XSS vulnerabilities. Every form is
vulnerable to CSRF. If they did anything with files in their script I may
be able to read arbitrary files to their server and/or upload and execute
arbitrary scripts. If they used eval() or system() I can probably execute
arbitrary shell code and take control of the entire site. If their server
is badly configured I could capture the entire machine.
This isn't a question of keeping software updated and not using
deprecated
functions, this is a question of discipline that is completely missing
among the unwashed masses as you call them. The intuitive way to handle
many of the most common PHP tasks is also the completely insecure way.
Philosophically, I wonder if we do a great disservice by encouraging
these
people to tinker with code at all. We do so knowing (or at least we
should
know) that anything they create will inevitably be hacked. We fuel the
widespread security
Re: [PHP-DEV] HEADS UP: 5.4 branch is open again
Hi Stats, I'll work on the patch for strict session patch so that both PHP 5.4 and 5.3 has the same functionality. I've also added 2 new escape functions to pgsql in trunk a while ago, pg_escape_literal()/pg_escape_identifier(). Is it okay to merge 5.4 branch also? You mentioned it's okay for 5.4.1, but double checking. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/3/2 Stas Malyshev smalys...@sugarcrm.com: Hi! When is cycle for 5.4.1 going to start? I got a few traits-related patches waiting for it. If you have some fixes, you can commit them now. Of course, the rules are as always in stable branch - no BC breaking, no major features :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- 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] HEADS UP: 5.4 branch is open again
On Fri, Mar 2, 2012 at 1:33 AM, David Soria Parra d...@php.net wrote: Hi internals, just a heads up. The PHP_5_4 branch is open for commits again. - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php On a somehow related topic: Now that we have 5.4 out, I have a question: Do we know what will be the next major release? If we want to follow the releaseprocess RFC, I think it would be nice to think about whether we plan to roll out a major or a minor version next. By the RFC, we can't do such changes to the language as we did with 5.2-5.3 or 5.3-5.4, because userland BC breaks aren't allowed. So I can see two way to address this: If we can agree upon the next version number beforehand, and we decide that we will go with the major release (be that php 6 or 7, whatever), we don't to do anything right now, we can branch the version from trunk/master, when the time comes. If we can't agree upon the next version number, or we agree upon that there will be an 5.5 version, I think it would make sense to create a branch for it ASAP, so there is place (trunk/master) for the approved but backward incompatible changes, and people don't have to hold patches. What do you think? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] get_magic_quotes_* != deprecated?
On 2 March 2012 01:56, Philip Olson phi...@roshambo.org wrote: Hello! Please clarify whether or not get_magic_quotes_gpc() and get_magic_quotes_runtime() are deprecated, because I do not think they are. Deprecated means people should not use them while writing new code, but they are perfectly sensible functions. They were, for a short time, marked as deprecated in the source. Bug #55371 was raised and they were changed back to not being deprecated. So going by the source and surrounding bugs and discussions, they're not deprecated. I propose that we do not describe get_magic_quotes_* as deprecated, and that they exist forever, and always return false. +1 Regards, Philip -- 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
+1 for the syntax. There are two nice side effects I would like to
underline.
1.
Error-raising can be clearly delegated to the type juggling mechanism.
There will be no need to implement anything new here but reuse the existing
type juggling system of PHP. That would be very consistent. At the end of
the day, these two syntaxes are completely equivalent:
function foo((int) $bar) { ... }
function foo($bar) { $bar = (int)$bar; ... }
2.
If we put passing by reference into the picture, it is easy to see why the
following syntax should be a parsing error:
function foo((int) $bar) { }// parsing error
On the contrary, were there no brackets, the resemblance to the syntax of C
would be confusing.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/2 Anthony Ferrara ircmax...@gmail.com
Hey all,
I know given all the discussion about this topic lately, this is a hot
topic. But I whipped together a quick POC patch to implement scalar
type casting for function parameters. Let me describe it:
Patch: https://gist.github.com/1947259
Example:
function foo( (int) $bar ) {
var_dump($bar);
}
foo(1); // int(1)
foo(1); // int(1)
foo(1.5); // int(1)
foo(foo); // E_RECOVERABLE_ERROR - Expected integer
foo(array()); // E_RECOVERABLE_ERROR
Right now, I only implemented the checks for (int), but I add the
parser constructs for (int), (float), (bool), (string) and (object)...
Now, let's talk why I did what I did:
Why did I use cast syntax? Well, there are really three main reasons.
First off, to indicate that a cast may happen. Second, to prevent
needing new tokens (and hence reserved words). And third to provide a
distinction between a string class type hint and a string scalar type
hint.
Why did I only implement (int)? Well, because I just wanted to build
a quick dirty POC that can be executed to see the semantics of
operation. There are issues with it now, so rather than doing all the
work to re-do it later, I just implemented int...
Why implement (object)? Because right now, there's no way to say you
want to accept a generic object without caring about type. So the
(object) cast/hint would then provide that ability to accept a generic
object.
Why not implement (resource)? Because that would require a new parser
token, as it's not available now...
How does the casting work? Right now, it's using a copy of the same
rules that internal functions use with zend_parse_parameters. That
way, it brings the operating semantics of internal functions and
userland functions more inline with each other.
So with that said, there are some (significant) issues with the patch:
1. First off, the arg checks happen before separation of the zval on
non-referenced calls. So that means the cast effects the original
zval AND the argument. Which is a no-go for a production patch. So
that means that the cast logic would need to be put after the zval
split. But we'd still want the checks first, so it's not too
difficult to segregate, just requires deeper changes. It's not
difficult (that I can see yet), just more work... Example of the
problem:
# sapi/cli/php -r 'function foo((int) $bar) { var_dump($bar); } $a =
1; foo($a); var_dump($a);'
int(1)
int(1)
2. Right now, the zend_aprse_arg_impl (
http://lxr.php.net/xref/PHP_5_4/Zend/zend_API.c#zend_parse_arg_impl )
that's used by internal functions is defined as static. So we'd be
copying a lot of the code back and forth. In the production patch,
I'd also want to re-factor that out a bit into either functions or
macros to handle the type conversion and casting in both places. That
way, both systems would behave identical (or as close as possible).
So, with that said, what do you think? Is this something worth
pursuing? Are there any fundamental issues that I'm missing? What
else would we need to cover in a production patch and RFC?
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Hi, All
Let me update my last functions as I got an inspiration from Anthony and
his proof-of-concept:
foo( (boolean) $b, (integer) $i, (float) $f, (string) $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;
// your code
}
Now here a rule I thought could be acceptable to differ between the
type-hint for classes and arrays and this notation:
If the type is wrapped in parentheses, the system will try to convert the
given value. Otherwise it will handle it strict.
Strict is currently only available for classes and arrays, and I don't want
to get more things in this list (excepted by resources, what is the last
what would make sense here).
Dynamic (the one with the parentheses) could then well be something like
boolean, integer, float, string and array. Array is also in this list as I
would like to have an option to give an object in here that implements all
interfaces that makes an object accessible as an array - for example
ArrayIterator.
Bye
Simon
2012/3/2 Simon Schick simonsimc...@googlemail.com
Hi, Kris
I have to confirm that that's not really what I wanted.
But many people were now talking about type-hint to scalar, but that was
maybe in another thread in this list :)
To get more to the point what were discussing about want:
Why not always (at least try) to transform the data?
In PHP 5.4 they've introduced quite a lot of new stuff around exactly that:
* Changed silent conversion of array to string to produce a notice.
* Changed silent casting of null/''/false into an Object when adding a
property into a warning.
I would suppose to add a type-hint for the following types:
* Boolean
* integer
* float
* string
Here's the last state what I thought about these type-hints ...
Both of the given examples here should give the same result:
foo(boolean $b, integer $i, float $f, string $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;
// your code
}
If you view it from that site - you can't get an array to do what you can
do with an object. Therefore I think it's quite OK to break the script
there, but here, as you can transform the values, I'd (at least try to)
transform the given data into the expected format.
The only thing I'm quite unsure about - should we trigger a E_WARNING or
E_NOTICE if we have data-loose in this transformation? Just let it pass as
it's transformable, but trigger some error ...
If you want to get a warning or notice in the function *foo2* then open a
new thread, as I think that should not be discussed here. It affects much
more than just the function-call.
p.s. What about adding another type-hint for resources?
That's something we could check by *is_resource()* and it would make
sense (at least to me).
Bye
Simon
2012/3/2 Kris Craig kris.cr...@gmail.com
I agree with what John said. Limiting the scope to scalars, while having
some advantages, probably wouldn't pass the usefulness test for most
people.
--Kris
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.com
wrote:
From: Richard Lynch [mailto:c...@l-i-e.com]
On Thu, March 1, 2012 2:38 am, John Crenshaw wrote:
You might consider those scripts poor programming practice. We all
do.
But PHP is the language of the unwashed masses, and that was, and
is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody
useful
web application, breaking 10,000 Computer Science rules along the
way.
And in 20 minutes I can hack into that application 20 different
ways.
This isn't really PHP's fault...or is it? By deliberately catering
to
the lowest possible denominator is it possible that PHP itself
contributes to the proliferation of wildly insecure web sites? I do
understand the unwashed masses argument, and yet, the security
geek
in me sometimes questions how good this is.
(Before someone flames me, I'm not really saying that we should
scrap
any foundational principles or tell basic users to go hang
themselves.
This is mostly philosophical musing.)
We make concerted efforts to educate scripters, by posting the same
thing in all our blogs.
Even if all they understand is Don't do this! it's good enough for
most of them.
Other times the decision was made to just deprecate a feature and
provide a migration path,
if suitable, but spread out over major
releases:
PHP x.0: Feature is bad, but there
PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP)
[This is the bit
where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature
is
just gone.
People who completely ignore docs or don't upgrade remain vulnerable,
but there's not much
you can do without making life miserable for a bazillion
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.com wrote: No, you've misunderstood. The average new not-really-a-developer has no concept of security. Every SQL query they write is vulnerable to injection. Every echo exposes their site to XSS vulnerabilities. Every form is vulnerable to CSRF. If they did anything with files in their script I may be able to read arbitrary files to their server and/or upload and execute arbitrary scripts. If they used eval() or system() I can probably execute arbitrary shell code and take control of the entire site. If their server is badly configured I could capture the entire machine. PHP is as vulnerable as you make it, This isn't a question of keeping software updated and not using deprecated functions, this is a question of discipline that is completely missing among the unwashed masses as you call them. The intuitive way to handle many of the most common PHP tasks is also the completely insecure way. Philosophically, I wonder if we do a great disservice by encouraging these people to tinker with code at all. We do so knowing (or at least we should know) that anything they create will inevitably be hacked. We fuel the widespread security problems that currently plague the web. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] discussions, about a 5.3 EOL
hi, 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, 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] [RFC] discussions, about a 5.3 EOL
Hi Pierre, Option 1 and 3 are the same ;-) Option 1 One year with bugs fixes followed by one year with security fixes only Option 2 Two years with security fixes only Option 3 One year with bugs fixes followed by one year with security fixes only Option 4 One year with security fixes only Michael On Mar 2, 2012, at 1:34 PM, Pierre Joye wrote: hi, 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, 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 -- 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
isnt option3 and option1 the same ? (unless i cant read properlly {very
possible})
On Fri, Mar 2, 2012 at 12:34 PM, Pierre Joye pierre@gmail.com wrote:
hi,
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,
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] [RFC] discussions, about a 5.3 EOL
fixed
On Fri, Mar 2, 2012 at 1:45 PM, Keloran ava...@gmail.com wrote:
isnt option3 and option1 the same ? (unless i cant read properlly {very
possible})
On Fri, Mar 2, 2012 at 12:34 PM, Pierre Joye pierre@gmail.com wrote:
hi,
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,
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
--
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
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...
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))...
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.
4. What about consistency? Well, there currently is no consistency.
Internal function parameters behave one way, and explicit casts behave
another. And even more confusing implicit casts behave yet another
way ($a + $b). So to implement this, we'd need to be consistent with
one of them. Frankly, I would only want to add consistency to
internal function parameters, since the explicit cast is not useful
IMHO (it's identical to $bar = (int) $bar), at which point it's not
worth adding to save only that one line. But if we're consistent with
internal function parameter checking, then it becomes quite useful.
We can throw warnings on unclean conversion and prevent execution of
the function... That way, all function calls behave the same (as much
as I hate the concept of warnings on type hint failure)... So, in
that case, function calls become an implicit cast to the type, which
is then why the stricter error handling (without breaking the spirit
or consistency).
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.
Thoughts? Should I update the patch to be more inline with what I
said above (the implicit hints that are offered by the current
internal function argument mechanism:
# sapi/cli/php -r 'function foo((int) $bar) { return $bar; } $a = 1;
var_dump(foo($a));'
int(1)
# sapi/cli/php -r 'function foo((int) $bar) { return $bar; } $a =
foo; var_dump(foo($a));'
Warning: Argument 1 passed to foo() must be of the type integer,
string given, called in Command line code on line 1 and defined in
Command line code on line 1
However, since it's not raising a terminating error, more changes
would need to be made to the VM to check the return status of the
argument check (which is currently ignored) to determine if to proceed
with the function call, or just return null imediately...
Thoughts?
Anthony
On Fri, Mar 2, 2012 at 5:27 AM, Lazare Inepologlou linep...@gmail.com wrote:
+1 for the syntax. There are two nice side effects I would like to
underline.
1.
Error-raising can be clearly delegated to the type juggling mechanism. There
will be no need to implement anything new here but reuse the existing type
juggling system of PHP. That would be very consistent. At the end of the
day, these two syntaxes are completely equivalent:
function foo((int) $bar) { ... }
function foo($bar) { $bar = (int)$bar; ... }
2.
If we put passing by reference into the picture, it is easy to see why the
following syntax should be a parsing error:
function foo((int) $bar) { } // parsing error
On the contrary, were there no brackets, the resemblance to the syntax of C
would be confusing.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/2 Anthony Ferrara ircmax...@gmail.com
Hey all,
I know given all the discussion about this topic lately, this is a hot
topic. But I whipped together a quick POC patch to implement scalar
type casting for function parameters. Let me describe it:
Patch: https://gist.github.com/1947259
Example:
function foo( (int) $bar ) {
var_dump($bar);
}
foo(1); // int(1)
foo(1); // int(1)
foo(1.5); // int(1)
foo(foo); // E_RECOVERABLE_ERROR - Expected integer
foo(array()); // E_RECOVERABLE_ERROR
Right now, I only implemented the checks for (int), but I add the
parser constructs for (int), (float), (bool), (string) and (object)...
Now, let's talk why I did what I did:
Why did I use cast syntax? Well, there are really three main reasons.
First off, to indicate that a cast may happen. Second, to prevent
needing new tokens (and hence reserved words). And third to provide a
distinction between a string class type hint and a string scalar type
hint.
Why did I only implement (int)? Well, because I just
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On Fri, 02 Mar 2012 13:34:21 +0100, Pierre Joye pierre@gmail.com wrote: hi, 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. I'd go with another option: One year of bug fixes, one year of security fixes and bug fixes that are trivial to backport. The truth is most of the time is less trouble to just merge the fix to oldstable than 1) determine if the bug is possibly exploitable 2) ask the RM for approval 3) merge the fix 4) probably then you also have to remove the entry from stable NEWS to oldstable NEWS Plus, 5.3 won't accumulate known bugs so quickly. -- Gustavo Lopes -- 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
Would it be worth while to discuss the possibility of LTS releases
(Long Term Support) with 5 or 7 year support (from time of initial
release)...?
5.3 is 2.5 years old now. Which means depending on the option that's
chosen here, it'll be completely out of support a mere 3.5 to 4.5
years after initial release. For a platform or program, that's fine.
But for a programming language, that seems a bit... short.
Instead, I'd like to see at least one current release be LTS, or
extended support which would then be covered by security fixes (at
the very least) for at least 5, and possibly 7 or even 10 years after
initial release.
If you think it's worth talking about, I'll whip up an RFC to go over
what I mean and more justification for it...
Thanks,
Anthony
On Fri, Mar 2, 2012 at 7:47 AM, Pierre Joye pierre@gmail.com wrote:
fixed
On Fri, Mar 2, 2012 at 1:45 PM, Keloran ava...@gmail.com wrote:
isnt option3 and option1 the same ? (unless i cant read properlly {very
possible})
On Fri, Mar 2, 2012 at 12:34 PM, Pierre Joye pierre@gmail.com wrote:
hi,
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,
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
--
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 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 Fri, Mar 2, 2012 at 1:56 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: I'd go with another option: One year of bug fixes, one year of security fixes and bug fixes that are trivial to backport. Won't work. It is then two years bug fixing. The idea of security only is to reduce both the amount of work and the risk to break it inadvertently. The truth is most of the time is less trouble to just merge the fix to oldstable than 1) determine if the bug is possibly exploitable 2) ask the RM for approval One has to do both anyway already. We have to request CVE for security issues and to ask RM for invasive fixes. 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] [RFC] discussions, about a 5.3 EOL
Hi, We already discussed LTS On Fri, Mar 2, 2012 at 2:00 PM, Anthony Ferrara ircmax...@gmail.com wrote: Would it be worth while to discuss the possibility of LTS releases (Long Term Support) with 5 or 7 year support (from time of initial release)...? 5.3 is 2.5 years old now. Which means depending on the option that's chosen here, it'll be completely out of support a mere 3.5 to 4.5 years after initial release. For a platform or program, that's fine. But for a programming language, that seems a bit... short. Instead, I'd like to see at least one current release be LTS, or extended support which would then be covered by security fixes (at the very least) for at least 5, and possibly 7 or even 10 years after initial release. It has been discussed already and it is impossible to do from our sides. RHEL, SEL or other distros do that on their side. For us, https://wiki.php.net/rfc/releaseprocess matters now. And the idea is how can we make 5.3 fits into that while having released before this RFC was approved. Please keep in mind that no matter the option, we will be over 3 years, that's pretty good (given too that 5.4 is almost 100% BC). 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] [RFC] discussions, about a 5.3 EOL
On Fri, 02 Mar 2012 14:00:51 +0100, Pierre Joye pierre@gmail.com wrote: On Fri, Mar 2, 2012 at 1:56 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: I'd go with another option: One year of bug fixes, one year of security fixes and bug fixes that are trivial to backport. Won't work. It is then two years bug fixing. The idea of security only is to reduce both the amount of work and the risk to break it inadvertently. The truth is most of the time is less trouble to just merge the fix to oldstable than 1) determine if the bug is possibly exploitable 2) ask the RM for approval One has to do both anyway already. We have to request CVE for security issues and to ask RM for invasive fixes. Fair enough. Option #1 seems the most appropriate then. The others seem too drastic to implement with such short notice. -- Gustavo Lopes -- 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 Fri, Mar 2, 2012 at 2:00 PM, Anthony Ferrara ircmax...@gmail.com wrote: Would it be worth while to discuss the possibility of LTS releases (Long Term Support) with 5 or 7 year support (from time of initial release)...? 5.3 is 2.5 years old now. Which means depending on the option that's chosen here, it'll be completely out of support a mere 3.5 to 4.5 years after initial release. For a platform or program, that's fine. But for a programming language, that seems a bit... short. Instead, I'd like to see at least one current release be LTS, or extended support which would then be covered by security fixes (at the very least) for at least 5, and possibly 7 or even 10 years after initial release. If you think it's worth talking about, I'll whip up an RFC to go over what I mean and more justification for it... there was a discussion about using lts versions: http://www.mail-archive.com/internals@lists.php.net/msg51086.html http://www.mail-archive.com/internals@lists.php.net/msg50773.html but there were no consensus about it. I think that we don't need an new RFC, we just need to answer the same questions which was just skipped (basically discussed to the death, but we couldn't reach a conclusion) back then: - how many concurrent releases do we want/can support - do we need lts releases, if so then how will we chose that -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On 2 March 2012 21:05, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: Fair enough. Option #1 seems the most appropriate then. The others seem too drastic to implement with such short notice. +1. We can't drop bug fixes immediately without warning, and I don't think the overhead of backporting security fixes is too onerous for one additional year, particularly in light of how significant a release PHP 5.3 was. Adam -- 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
btw, thanks for those who keep the discussion focused on 5.3 EOL :-) For the votes, the votes phase will begin next week :) On Fri, Mar 2, 2012 at 2:12 PM, Adam Harvey ahar...@php.net wrote: On 2 March 2012 21:05, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: Fair enough. Option #1 seems the most appropriate then. The others seem too drastic to implement with such short notice. +1. We can't drop bug fixes immediately without warning, and I don't think the overhead of backporting security fixes is too onerous for one additional year, particularly in light of how significant a release PHP 5.3 was. Adam -- 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] [RFC] discussions, about a 5.3 EOL
On 2 March 2012 21:34, Simon Schick simonsimc...@googlemail.com wrote: One or two years is way to short if you'd ask me. A major release should be supported with all kind of bug fixes for min. 3 years after a new release has been brought out. Specially if it's a wide-spread language like PHP that has been implemented by such big and lazy companies. Please do not misunderstand that. Lazy is not meant in the way that they are doing nothing, but that it takes way more time as it does for me installing a new PHP version on my 2-3 servers. There has to be a limit at some point because the maintenance burden becomes too difficult. With the two year proposals, we're going to end up in a position next year where we'll have active 5.3, 5.4, 5.5, 5.6 and trunk trees (or whatever 5.5 and 5.6 get numbered). That's at least one too many, frankly, but there was always going to be some awkwardness during the transition to the new release process and I for one would prefer to err on the side of caution. Honestly, I'd probably prefer 9 months of bug fixes (up to the release of 5.5 in November/December) + 9 months of security fixes, but I don't want to muddy Pierre's RFC further, and I'd like to hear the opinions of the RMs, since this is very much on them. The point of the release process RFC was to clarify this — releases from 5.4 onwards have a clearly defined two year bug fix + one year security fix lifetime. I think that's reasonable, and it falls into line pretty well with a number of other languages. The fact that we're in this position is a one-off, and I don't think we can prolong it indefinitely (nor do we really have the resources to). Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZEND_MM_SMALL_FREE_BUCKET and ZEND_MM_REST_BUCKET
Laruence and I wrote articles about ZendMM internals. You would find them at http://www.laruence.com/2011/11/09/2277.html and http://julien-pauli.developpez.com/tutoriels/php/internals/zend-memory-manager/ . You can use any translator to get them in English For basic use, see the readme at http://lxr.php.net/xref/PHP_5_4/Zend/README.ZEND_MM Hope this helps :) Julien.P On Fri, Mar 2, 2012 at 1:51 PM, Adi Mutu adi_mut...@yahoo.com wrote: Hello, Can somebody shed some light on these 2 defines? Thanks. #define ZEND_MM_SMALL_FREE_BUCKET(heap, index) \ (zend_mm_free_block*) ((char*)heap-free_buckets[index * 2] + \ sizeof(zend_mm_free_block*) * 2 - \ sizeof(zend_mm_small_free_block)) #define ZEND_MM_REST_BUCKET(heap) \ (zend_mm_free_block*)((char*)heap-rest_buckets[0] + \ sizeof(zend_mm_free_block*) * 2 - \ sizeof(zend_mm_small_free_block))
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On Fri, Mar 2, 2012 at 2:43 PM, Adam Harvey ahar...@php.net wrote: On 2 March 2012 21:34, Simon Schick simonsimc...@googlemail.com wrote: One or two years is way to short if you'd ask me. A major release should be supported with all kind of bug fixes for min. 3 years after a new release has been brought out. Specially if it's a wide-spread language like PHP that has been implemented by such big and lazy companies. Please do not misunderstand that. Lazy is not meant in the way that they are doing nothing, but that it takes way more time as it does for me installing a new PHP version on my 2-3 servers. There has to be a limit at some point because the maintenance burden becomes too difficult. With the two year proposals, we're going to end up in a position next year where we'll have active 5.3, 5.4, 5.5, 5.6 and trunk trees (or whatever 5.5 and 5.6 get numbered). That's at least one too many, frankly, but there was always going to be some awkwardness during the transition to the new release process and I for one would prefer to err on the side of caution. Honestly, I'd probably prefer 9 months of bug fixes (up to the release of 5.5 in November/December) + 9 months of security fixes, but I don't want to muddy Pierre's RFC further, and I'd like to hear the opinions of the RMs, since this is very much on them. The point of the release process RFC was to clarify this — releases from 5.4 onwards have a clearly defined two year bug fix + one year security fix lifetime. I think that's reasonable, and it falls into line pretty well with a number of other languages. The fact that we're in this position is a one-off, and I don't think we can prolong it indefinitely (nor do we really have the resources to). Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I'm OK for option #1 The RM should have things to tell from their side and from past experiences. About LTS, I think it's not our job. Any company that would need LTS should just ask for it from its OS Support, that's their job. Julien.P
Re: [PHP-DEV] ZEND_MM_SMALL_FREE_BUCKET and ZEND_MM_REST_BUCKET
Thanks Julien, but i've already read your article using translator and did not found an answer to that (i've also sent you an email about Zend mm a few days ago) laurence site looks down to me. Perhaps the link is wrong? Thanks, A. From: jpauli jpa...@php.net To: Adi Mutu adi_mut...@yahoo.com Cc: internals@lists.php.net internals@lists.php.net Sent: Friday, March 2, 2012 3:43 PM Subject: Re: [PHP-DEV] ZEND_MM_SMALL_FREE_BUCKET and ZEND_MM_REST_BUCKET Laruence and I wrote articles about ZendMM internals. You would find them at http://www.laruence.com/2011/11/09/2277.html and http://julien-pauli.developpez.com/tutoriels/php/internals/zend-memory-manager/ . You can use any translator to get them in English For basic use, see the readme at http://lxr.php.net/xref/PHP_5_4/Zend/README.ZEND_MM Hope this helps :) Julien.P On Fri, Mar 2, 2012 at 1:51 PM, Adi Mutu adi_mut...@yahoo.com wrote: Hello, Can somebody shed some light on these 2 defines? Thanks. #define ZEND_MM_SMALL_FREE_BUCKET(heap, index) \ (zend_mm_free_block*) ((char*)heap-free_buckets[index * 2] + \ sizeof(zend_mm_free_block*) * 2 - \ sizeof(zend_mm_small_free_block)) #define ZEND_MM_REST_BUCKET(heap) \ (zend_mm_free_block*)((char*)heap-rest_buckets[0] + \ sizeof(zend_mm_free_block*) * 2 - \ sizeof(zend_mm_small_free_block))
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
Hi, all It's really hard to make a decision here because you also have to care about big companies in one way, that have not updated to PHP 5.3 now ... But instead of that I read some posts from November last year that they have PHP6 in their control-panel, what is basically PHP 5.4 beta ... One or two years is way to short if you'd ask me. A major release should be supported with all kind of bug fixes for min. 3 years after a new release has been brought out. Specially if it's a wide-spread language like PHP that has been implemented by such big and lazy companies. Please do not misunderstand that. Lazy is not meant in the way that they are doing nothing, but that it takes way more time as it does for me installing a new PHP version on my 2-3 servers. Bye Simon 2012/3/2 Adam Harvey ahar...@php.net On 2 March 2012 21:05, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: Fair enough. Option #1 seems the most appropriate then. The others seem too drastic to implement with such short notice. +1. We can't drop bug fixes immediately without warning, and I don't think the overhead of backporting security fixes is too onerous for one additional year, particularly in light of how significant a release PHP 5.3 was. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZEND_MM_SMALL_FREE_BUCKET and ZEND_MM_REST_BUCKET
On Fri, Mar 2, 2012 at 2:57 PM, Adi Mutu adi_mut...@yahoo.com wrote: Thanks Julien, but i've already read your article using translator and did not found an answer to that (i've also sent you an email about Zend mm a few days ago) laurence site looks down to me. Perhaps the link is wrong? Thanks, A. I blame the Great Firewall of China could you try that the following link works for you: http://translate.google.com/translate?sl=zh-CNtl=enjs=nprev=_thl=huie=UTF-8layout=2eotf=1u=http%3A%2F%2Fwww.laruence.com%2F2011%2F11%2F09%2F2277.html -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On 03/02/2012 07:34 AM, Pierre Joye wrote: https://wiki.php.net/rfc/php53eol One year with bugs fixes (both security and normal bugs) seems to be the only feasible option to me. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZEND_MM_SMALL_FREE_BUCKET and ZEND_MM_REST_BUCKET
Now that's really awesome.:) I have to do something so i can access and subscribe to that blog. Are you serious about that firewall? That would be my first time i actually encounter a problem because of this. From: Ferenc Kovacs tyr...@gmail.com To: Adi Mutu adi_mut...@yahoo.com Cc: jpauli jpa...@php.net; internals@lists.php.net internals@lists.php.net Sent: Friday, March 2, 2012 4:00 PM Subject: Re: [PHP-DEV] ZEND_MM_SMALL_FREE_BUCKET and ZEND_MM_REST_BUCKET On Fri, Mar 2, 2012 at 2:57 PM, Adi Mutu adi_mut...@yahoo.com wrote: Thanks Julien, but i've already read your article using translator and did not found an answer to that (i've also sent you an email about Zend mm a few days ago) laurence site looks down to me. Perhaps the link is wrong? Thanks, A. I blame the Great Firewall of China could you try that the following link works for you: http://translate.google.com/translate?sl=zh-CNtl=enjs=nprev=_thl=huie=UTF-8layout=2eotf=1u=http%3A%2F%2Fwww.laruence.com%2F2011%2F11%2F09%2F2277.html -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On 03/02/2012 08:34 AM, Simon Schick wrote: It's really hard to make a decision here because you also have to care about big companies in one way, that have not updated to PHP 5.3 now Such companies are using LTS releases of their OS distribution (RHEL, SLES, ...) where the vendor will take care of backporting PHP fixes. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZEND_MM_SMALL_FREE_BUCKET and ZEND_MM_REST_BUCKET
On Fri, Mar 2, 2012 at 2:57 PM, Adi Mutu adi_mut...@yahoo.com wrote: Thanks Julien, but i've already read your article using translator and did not found an answer to that (i've also sent you an email about Zend mm a few days ago) Not seen that. Anyway, I dont master all ZendMM stuff, I couldn't explain every line of code. It's been mainly designed back in 2005, I wasn't here yet :) It's not very hard to guess what it does, if you know how a memory manager works. Basically, it does stuff that malloc() does internally, stuff explained here, for example ( http://www.phrack.org/issues.html?issue=57id=9#article) ; but for PHP needs, and with multi-platform in mind. Julien.P laurence site looks down to me. Perhaps the link is wrong? Thanks, A. From: jpauli jpa...@php.net To: Adi Mutu adi_mut...@yahoo.com Cc: internals@lists.php.net internals@lists.php.net Sent: Friday, March 2, 2012 3:43 PM Subject: Re: [PHP-DEV] ZEND_MM_SMALL_FREE_BUCKET and ZEND_MM_REST_BUCKET Laruence and I wrote articles about ZendMM internals. You would find them at http://www.laruence.com/2011/11/09/2277.html and http://julien-pauli.developpez.com/tutoriels/php/internals/zend-memory-manager/ . You can use any translator to get them in English For basic use, see the readme at http://lxr.php.net/xref/PHP_5_4/Zend/README.ZEND_MM Hope this helps :) Julien.P On Fri, Mar 2, 2012 at 1:51 PM, Adi Mutu adi_mut...@yahoo.com wrote: Hello, Can somebody shed some light on these 2 defines? Thanks. #define ZEND_MM_SMALL_FREE_BUCKET(heap, index) \ (zend_mm_free_block*) ((char*)heap-free_buckets[index * 2] + \ sizeof(zend_mm_free_block*) * 2 - \ sizeof(zend_mm_small_free_block)) #define ZEND_MM_REST_BUCKET(heap) \ (zend_mm_free_block*)((char*)heap-rest_buckets[0] + \ sizeof(zend_mm_free_block*) * 2 - \ sizeof(zend_mm_small_free_block))
Re: [PHP-DEV] ZEND_MM_SMALL_FREE_BUCKET and ZEND_MM_REST_BUCKET
On Fri, Mar 2, 2012 at 8:51 PM, Adi Mutu adi_mut...@yahoo.com wrote: Hello, Can somebody shed some light on these 2 defines? Thanks. #define ZEND_MM_SMALL_FREE_BUCKET(heap, index) \ (zend_mm_free_block*) ((char*)heap-free_buckets[index * 2] + \ sizeof(zend_mm_free_block*) * 2 - \ sizeof(zend_mm_small_free_block)) #define ZEND_MM_REST_BUCKET(heap) \ (zend_mm_free_block*)((char*)heap-rest_buckets[0] + \ sizeof(zend_mm_free_block*) * 2 - \ sizeof(zend_mm_small_free_block)) Hi: the first MACRO is a tricky way to put a number of ZEND_NUM_BUCKETS zend_mm_buckects into a fixed length array. and yes, my site might be blocked by chinese GFW, but you can try this: https://wiki.php.net/internals/zend_mm plz see the red part of the first picture.. thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZEND_MM_SMALL_FREE_BUCKET and ZEND_MM_REST_BUCKET
On Fri, Mar 2, 2012 at 10:12 PM, Adi Mutu adi_mut...@yahoo.com wrote: Now that's really awesome.:) I have to do something so i can access and subscribe to that blog. Hi: Google reader is a good choice~ :) I am so glad you like it. thanks . Are you serious about that firewall? That would be my first time i actually encounter a problem because of this. From: Ferenc Kovacs tyr...@gmail.com To: Adi Mutu adi_mut...@yahoo.com Cc: jpauli jpa...@php.net; internals@lists.php.net internals@lists.php.net Sent: Friday, March 2, 2012 4:00 PM Subject: Re: [PHP-DEV] ZEND_MM_SMALL_FREE_BUCKET and ZEND_MM_REST_BUCKET On Fri, Mar 2, 2012 at 2:57 PM, Adi Mutu adi_mut...@yahoo.com wrote: Thanks Julien, but i've already read your article using translator and did not found an answer to that (i've also sent you an email about Zend mm a few days ago) laurence site looks down to me. Perhaps the link is wrong? Thanks, A. I blame the Great Firewall of China could you try that the following link works for you: http://translate.google.com/translate?sl=zh-CNtl=enjs=nprev=_thl=huie=UTF-8layout=2eotf=1u=http%3A%2F%2Fwww.laruence.com%2F2011%2F11%2F09%2F2277.html -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZEND_MM_SMALL_FREE_BUCKET and ZEND_MM_REST_BUCKET
Already added in google reader..now i see the site is accesible also, strange. I've looked at the picture, read your explanation, but i still didn't get it.i'll think some more about this and perhaps i'll suggest you a better translation at the end. Thanks! From: Laruence larue...@php.net To: Adi Mutu adi_mut...@yahoo.com Cc: Ferenc Kovacs tyr...@gmail.com; jpauli jpa...@php.net; internals@lists.php.net internals@lists.php.net Sent: Friday, March 2, 2012 4:52 PM Subject: Re: [PHP-DEV] ZEND_MM_SMALL_FREE_BUCKET and ZEND_MM_REST_BUCKET On Fri, Mar 2, 2012 at 10:12 PM, Adi Mutu adi_mut...@yahoo.com wrote: Now that's really awesome.:) I have to do something so i can access and subscribe to that blog. Hi: Google reader is a good choice~ :) I am so glad you like it. thanks . Are you serious about that firewall? That would be my first time i actually encounter a problem because of this. From: Ferenc Kovacs tyr...@gmail.com To: Adi Mutu adi_mut...@yahoo.com Cc: jpauli jpa...@php.net; internals@lists.php.net internals@lists.php.net Sent: Friday, March 2, 2012 4:00 PM Subject: Re: [PHP-DEV] ZEND_MM_SMALL_FREE_BUCKET and ZEND_MM_REST_BUCKET On Fri, Mar 2, 2012 at 2:57 PM, Adi Mutu adi_mut...@yahoo.com wrote: Thanks Julien, but i've already read your article using translator and did not found an answer to that (i've also sent you an email about Zend mm a few days ago) laurence site looks down to me. Perhaps the link is wrong? Thanks, A. I blame the Great Firewall of China could you try that the following link works for you: http://translate.google.com/translate?sl=zh-CNtl=enjs=nprev=_thl=huie=UTF-8layout=2eotf=1u=http%3A%2F%2Fwww.laruence.com%2F2011%2F11%2F09%2F2277.html -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Laruence Xinchen Hui http://www.laruence.com/
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
Am 02.03.2012 15:15, schrieb Sebastian Bergmann: On 03/02/2012 08:34 AM, Simon Schick wrote: It's really hard to make a decision here because you also have to care about big companies in one way, that have not updated to PHP 5.3 now Such companies are using LTS releases of their OS distribution (RHEL, SLES, ...) where the vendor will take care of backporting PHP fixes. SLES 11 SP2 got out this week, finally shipping PHP 5.3 for the first time. They did a pretty good job maintaining their 5.2 product (which is still included as an unsupported option). Enterprise distributions are both slow and stable. I don't think php development should commit to unpaid long term support. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- 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 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. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- 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
I like that. That way there will always be 2 stable maintained versions, and possibly a third (depending on timing) that's security only... Solves the problem quite nicely IMHO... Anthony On Fri, Mar 2, 2012 at 10:41 AM, 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. -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- 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] [RFC] discussions, about a 5.3 EOL
hi Sebastian, On Fri, Mar 2, 2012 at 4:41 PM, 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? And when do you think it is one year after php-next? In two years. So much about one year being the only option ;-) 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] [RFC] discussions, about a 5.3 EOL
On Fri, Mar 2, 2012 at 4:54 PM, Pierre Joye pierre@gmail.com wrote: hi Sebastian, On Fri, Mar 2, 2012 at 4:41 PM, 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? And when do you think it is one year after php-next? In two years. So much about one year being the only option ;-) that's just the schedule, if the php-next is being late(which can happen, 3-4 additional RC can cause a 2 month delay), that will force us to either prolong the support of php-old (which would be in contrast with the RFC) or the dates would start shifting apart. if the next-next is also delayed 2 month, then it will be only an 8 months gap between the release of php-next and the EOL of php-old, and I think that would be a trend, because projects tend to being late. so I would support Sebastian's proposal, and there are other projects doing this kind of schedule (debian and fedora comes to mind, but I'm sure there are plenty of others) -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On Fri, Mar 2, 2012 at 5:04 PM, Ferenc Kovacs tyr...@gmail.com wrote: that's just the schedule Yes, and as of now this is the plan. The idea is the same, that does not affect the EOL of 5.3 is php-next is a month late, not at all. 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] [RFC] discussions, about a 5.3 EOL
On Fri, Mar 2, 2012 at 5:06 PM, Pierre Joye pierre@gmail.com wrote: On Fri, Mar 2, 2012 at 5:04 PM, Ferenc Kovacs tyr...@gmail.com wrote: that's just the schedule Yes, and as of now this is the plan. The idea is the same, that does not affect the EOL of 5.3 is php-next is a month late, not at all. yep, and I explained why I think that it is a bad idea if the releases and the EOLs can shift apart. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Google Summer of Code
On Thu, Mar 1, 2012 at 21:00, Adam Harvey ahar...@php.net wrote: - New Mirror Management System (Daniel Brown): not sure if this is relevant — systems guys? Daniel? No, the system I had been drafting was mainly to fix a few issues and introduce some new features to make mirror management easier. In the intervening years, I've done the majority of what I'd set out to do (but didn't rewrite it as the original project scope would've done). So this is no longer relevant; I'll remove it today. - Revamping user comments at php.net (Philip Olson): might also be a bit thin as written, but it depends on where it goes. From discussions I've seen over the years on the official GSOC list, this may be wrapped into the blanket rejection on documentation. -- /Daniel P. Brown Dedicated Servers, Cloud and Cloud Hybrid Solutions, VPS, Hosting (866-) 725-4321 http://www.parasane.net/ -- 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
they are totally unrelated. The discussion here is not about whether next will be late but when 5.3 will end. The key here is not the date itself but the ability for hosting companies, distros, etc. to plan a migration or an EOL. One or two months less or more do not change anything, as long as the support of a given branch is inside the plan (three years from every new release from 5.4 and later). On Fri, Mar 2, 2012 at 5:14 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Fri, Mar 2, 2012 at 5:06 PM, Pierre Joye pierre@gmail.com wrote: On Fri, Mar 2, 2012 at 5:04 PM, Ferenc Kovacs tyr...@gmail.com wrote: that's just the schedule Yes, and as of now this is the plan. The idea is the same, that does not affect the EOL of 5.3 is php-next is a month late, not at all. yep, and I explained why I think that it is a bad idea if the releases and the EOLs can shift apart. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- 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] [RFC] discussions, about a 5.3 EOL
On 03/02/2012 10:54 AM, Pierre Joye wrote: And when do you think it is one year after php-next? In two years. So much about one year being the only option ;-) I am capable of learning, but that's besides the point. The point is static (two years after release) vs. dynamic (one year after next release). In a perfect world those two are the same. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- 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
hi Sebastian, Thing is that we already have well defined lifecycle for anything after 5.4. So the question is only about 5.3. That's why, given that it is already a couple of years old, I would rather go with a statically defined EOL now. As php-next is very unlikely to be the moment where people will suddenly migrate. For any future release, it is static, release date + three years. On Fri, Mar 2, 2012 at 5:44 PM, Sebastian Bergmann sebast...@php.net wrote: On 03/02/2012 10:54 AM, Pierre Joye wrote: And when do you think it is one year after php-next? In two years. So much about one year being the only option ;-) I am capable of learning, but that's besides the point. The point is static (two years after release) vs. dynamic (one year after next release). In a perfect world those two are the same. -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- 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] [RFC] discussions, about a 5.3 EOL
Excerpts from Sebastian Bergmann's message of Fri Mar 02 07:41:53 -0800 2012: 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. Just chiming in from the Ubuntu side of things. I think this is the most predictable, and helpful plan for users and for distributors. From the user standpoint, its quite useful to know where you stand for upgrade path. This should make conservative users comfortable with using 5.3 on existing projects until 5.5 enters RC phase, and then they can start evaluating their options to move to 5.5 or 5.4, as they know they'll have a whole year to evaluate 5.5. If you put a clock on 5.3, and 5.5 slips for legitimate reasons, then they'll be stuck with 5.4 only, and you may actually *miss* the opportunity to get people on the latest release. From a distribution standpoint, anything that lengthens the amount of time that PHP as a project fully supports a release makes our burden smaller, and gives our users a better chance at having stable software for the entire life of our LTS releases. Selfish, I know, but just stating the obvious fact. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] GIT commit mails
Hi! Can we please fix the GIT commit mails before we move anything else over? cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZEND_MM_SMALL_FREE_BUCKET and ZEND_MM_REST_BUCKET
Hi! #define ZEND_MM_SMALL_FREE_BUCKET(heap, index) \ (zend_mm_free_block*) ((char*)heap-free_buckets[index * 2] + \ sizeof(zend_mm_free_block*) * 2 - \ sizeof(zend_mm_small_free_block)) #define ZEND_MM_REST_BUCKET(heap) \ (zend_mm_free_block*)((char*)heap-rest_buckets[0] + \ sizeof(zend_mm_free_block*) * 2 - \ sizeof(zend_mm_small_free_block)) IIRC the purpose of these defines is that the MM caches small free blocks so that it could find them faster, so that for example allocating zvals (frequent case) goes faster. So it has a small cache for such blocks, by size, so the allocator can for example quickly find a free block of size of zval or of size of Hashtable. These macros try to find such free block for given small size (first one) or for the rest of blocks (i.e. bigger blocks which share one free list). -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GIT commit mails
What's the problem you're having with them? --Kris On Fri, Mar 2, 2012 at 10:36 AM, Derick Rethans der...@php.net wrote: Hi! Can we please fix the GIT commit mails before we move anything else over? cheers, Derick -- 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
I'm probably missing something, but why not just do it like we did with 5.2? I.e. we keep maintaining it until PHP 5.5, at which time we deprecate it and be done with it? Like I said, I'm probably missing something lol, so if someone could explain why this is different I'd be much obliged! =) --Kris On Fri, Mar 2, 2012 at 9:39 AM, Clint Byrum cl...@ubuntu.com wrote: Excerpts from Sebastian Bergmann's message of Fri Mar 02 07:41:53 -0800 2012: 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. Just chiming in from the Ubuntu side of things. I think this is the most predictable, and helpful plan for users and for distributors. From the user standpoint, its quite useful to know where you stand for upgrade path. This should make conservative users comfortable with using 5.3 on existing projects until 5.5 enters RC phase, and then they can start evaluating their options to move to 5.5 or 5.4, as they know they'll have a whole year to evaluate 5.5. If you put a clock on 5.3, and 5.5 slips for legitimate reasons, then they'll be stuck with 5.4 only, and you may actually *miss* the opportunity to get people on the latest release. From a distribution standpoint, anything that lengthens the amount of time that PHP as a project fully supports a release makes our burden smaller, and gives our users a better chance at having stable software for the entire life of our LTS releases. Selfish, I know, but just stating the obvious fact. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GIT commit mails
On Mar 2, 2012, at 10:36 AM, Derick Rethans wrote: Hi! Can we please fix the GIT commit mails before we move anything else over? +1 Regards, Philip -- 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
again, we have a clear EOL process now for 5.4 and later. Only 5.3 does not have any. We have to define it now instead of doing it in 1-2 years without giving our users any kind of reasonable delay to plan a migration. Cheers, On Fri, Mar 2, 2012 at 7:54 PM, Kris Craig kris.cr...@gmail.com wrote: I'm probably missing something, but why not just do it like we did with 5.2? I.e. we keep maintaining it until PHP 5.5, at which time we deprecate it and be done with it? Like I said, I'm probably missing something lol, so if someone could explain why this is different I'd be much obliged! =) --Kris On Fri, Mar 2, 2012 at 9:39 AM, Clint Byrum cl...@ubuntu.com wrote: Excerpts from Sebastian Bergmann's message of Fri Mar 02 07:41:53 -0800 2012: 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. Just chiming in from the Ubuntu side of things. I think this is the most predictable, and helpful plan for users and for distributors. From the user standpoint, its quite useful to know where you stand for upgrade path. This should make conservative users comfortable with using 5.3 on existing projects until 5.5 enters RC phase, and then they can start evaluating their options to move to 5.5 or 5.4, as they know they'll have a whole year to evaluate 5.5. If you put a clock on 5.3, and 5.5 slips for legitimate reasons, then they'll be stuck with 5.4 only, and you may actually *miss* the opportunity to get people on the latest release. From a distribution standpoint, anything that lengthens the amount of time that PHP as a project fully supports a release makes our burden smaller, and gives our users a better chance at having stable software for the entire life of our LTS releases. Selfish, I know, but just stating the obvious fact. -- 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] HEADS UP: 5.4 branch is open again
From the timelines I've seen floating around, I was under the impression that the next one would be 5.5, followed by 5.6, etc. PHP 6 is at least a few years off according to every projection I've seen. --Kris On Fri, Mar 2, 2012 at 1:26 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Fri, Mar 2, 2012 at 1:33 AM, David Soria Parra d...@php.net wrote: Hi internals, just a heads up. The PHP_5_4 branch is open for commits again. - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php On a somehow related topic: Now that we have 5.4 out, I have a question: Do we know what will be the next major release? If we want to follow the releaseprocess RFC, I think it would be nice to think about whether we plan to roll out a major or a minor version next. By the RFC, we can't do such changes to the language as we did with 5.2-5.3 or 5.3-5.4, because userland BC breaks aren't allowed. So I can see two way to address this: If we can agree upon the next version number beforehand, and we decide that we will go with the major release (be that php 6 or 7, whatever), we don't to do anything right now, we can branch the version from trunk/master, when the time comes. If we can't agree upon the next version number, or we agree upon that there will be an 5.5 version, I think it would make sense to create a branch for it ASAP, so there is place (trunk/master) for the approved but backward incompatible changes, and people don't have to hold patches. What do you think? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] HEADS UP: 5.4 branch is open again
that's totally off topic... but we have no idea yet when will be php 6, or whatsoever. However next is in around a year :) On Fri, Mar 2, 2012 at 8:00 PM, Kris Craig kris.cr...@gmail.com wrote: From the timelines I've seen floating around, I was under the impression that the next one would be 5.5, followed by 5.6, etc. PHP 6 is at least a few years off according to every projection I've seen. --Kris On Fri, Mar 2, 2012 at 1:26 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Fri, Mar 2, 2012 at 1:33 AM, David Soria Parra d...@php.net wrote: Hi internals, just a heads up. The PHP_5_4 branch is open for commits again. - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php On a somehow related topic: Now that we have 5.4 out, I have a question: Do we know what will be the next major release? If we want to follow the releaseprocess RFC, I think it would be nice to think about whether we plan to roll out a major or a minor version next. By the RFC, we can't do such changes to the language as we did with 5.2-5.3 or 5.3-5.4, because userland BC breaks aren't allowed. So I can see two way to address this: If we can agree upon the next version number beforehand, and we decide that we will go with the major release (be that php 6 or 7, whatever), we don't to do anything right now, we can branch the version from trunk/master, when the time comes. If we can't agree upon the next version number, or we agree upon that there will be an 5.5 version, I think it would make sense to create a branch for it ASAP, so there is place (trunk/master) for the approved but backward incompatible changes, and people don't have to hold patches. What do you think? -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- 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] GIT commit mails
On Fri, Mar 2, 2012 at 7:47 PM, Kris Craig kris.cr...@gmail.com wrote: What's the problem you're having with them? --Kris http://comments.gmane.org/gmane.comp.php.devel/70417 the commit mail format is different on the current git setup than the current svn setup. for svn there is one email for each commit and the mail subject contains (for a limited length) the paths for the modified files. Derick filters the commits mails based on the subject, which is not possible with the current git mails (please read the mails before arguing that he can filter it otherwise). to solve that we came up with the idea to have a mail for each push, followed by a mail for each commit, it is under development, but isn't done yet (AFAIR Irker is working on it) -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
Ok, I'm up to speed now. I agree that Option 1 is the best approach. --Kris On Fri, Mar 2, 2012 at 10:58 AM, Pierre Joye pierre@gmail.com wrote: again, we have a clear EOL process now for 5.4 and later. Only 5.3 does not have any. We have to define it now instead of doing it in 1-2 years without giving our users any kind of reasonable delay to plan a migration. Cheers, On Fri, Mar 2, 2012 at 7:54 PM, Kris Craig kris.cr...@gmail.com wrote: I'm probably missing something, but why not just do it like we did with 5.2? I.e. we keep maintaining it until PHP 5.5, at which time we deprecate it and be done with it? Like I said, I'm probably missing something lol, so if someone could explain why this is different I'd be much obliged! =) --Kris On Fri, Mar 2, 2012 at 9:39 AM, Clint Byrum cl...@ubuntu.com wrote: Excerpts from Sebastian Bergmann's message of Fri Mar 02 07:41:53 -0800 2012: 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. Just chiming in from the Ubuntu side of things. I think this is the most predictable, and helpful plan for users and for distributors. From the user standpoint, its quite useful to know where you stand for upgrade path. This should make conservative users comfortable with using 5.3 on existing projects until 5.5 enters RC phase, and then they can start evaluating their options to move to 5.5 or 5.4, as they know they'll have a whole year to evaluate 5.5. If you put a clock on 5.3, and 5.5 slips for legitimate reasons, then they'll be stuck with 5.4 only, and you may actually *miss* the opportunity to get people on the latest release. From a distribution standpoint, anything that lengthens the amount of time that PHP as a project fully supports a release makes our burden smaller, and gives our users a better chance at having stable software for the entire life of our LTS releases. Selfish, I know, but just stating the obvious fact. -- 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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
Hi, the primary goal should be to encourage people to move to 5.4 as soon as possible. The clear marketing message should be along the lines of PHP 5.4 is the best version there is, it has all of 5.3's bug fixes and additional improvements. We have to drive the 5.4 adoption. I also don't think it's a till that date all kinds of fixes and from then on suddenly security only thing. For one due to the fact that there are always enough corner cases and for the second that regular bug fixing will phase out naturally (Oh this is such a corner case I won't validate it on 5.3, rather spend time on the next bug). If we force developers too much to verify and fix on multiple trees they either blindly commit without testing[1] or don't fix bugs at all. In the end most contributors do this voluntarily for fun (or ego or ...). So to sum it all up: I would prefer to promise security fixes only to the outside (2 years if people here think that's a good time) and then, as a group, agree to do additional bug fixing during that time. johannes [1] Remember the PHP 6 story: There were enough commits 1:1 from 5.2 applied which sometimes didn't even compile. On Fri, 2012-03-02 at 13:34 +0100, Pierre Joye wrote: hi, 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, 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] [RFC] discussions, about a 5.3 EOL
Kris Craig wrote: I'm probably missing something, but why not just do it like we did with 5.2? I.e. we keep maintaining it until PHP 5.5, at which time we deprecate it and be done with it? Like I said, I'm probably missing something lol, so if someone could explain why this is different I'd be much obliged! =) Certainly I can see many people who have only just finally updated thing to work on PHP5.3 might well skip 5.4 and then look to another update when 5.5 comes out. Stopping security updates on 5.3 and then not providing 5.5 for another couple of months while not particularly problematic does seem to be a little irritating, but a fixed timetable that should provide an overlap would be ideal ... with the flexibility to move the deadline if there IS some major reason that 5.5 has not been released as currently planned? -- 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] ZEND_MM_SMALL_FREE_BUCKET and ZEND_MM_REST_BUCKET
I think that caching part you're talking about is in function zend_mm_alloc_int..i don't see what caching has to do with these macros... but i maybe mistaking of course. What i don't understand is those additions and substracting in those macros..but i'll read more tomorrow. From: Stas Malyshev smalys...@sugarcrm.com To: Adi Mutu adi_mut...@yahoo.com Cc: internals@lists.php.net internals@lists.php.net Sent: Friday, March 2, 2012 8:44 PM Subject: Re: [PHP-DEV] ZEND_MM_SMALL_FREE_BUCKET and ZEND_MM_REST_BUCKET Hi! #define ZEND_MM_SMALL_FREE_BUCKET(heap, index) \ (zend_mm_free_block*) ((char*)heap-free_buckets[index * 2] + \ sizeof(zend_mm_free_block*) * 2 - \ sizeof(zend_mm_small_free_block)) #define ZEND_MM_REST_BUCKET(heap) \ (zend_mm_free_block*)((char*)heap-rest_buckets[0] + \ sizeof(zend_mm_free_block*) * 2 - \ sizeof(zend_mm_small_free_block)) IIRC the purpose of these defines is that the MM caches small free blocks so that it could find them faster, so that for example allocating zvals (frequent case) goes faster. So it has a small cache for such blocks, by size, so the allocator can for example quickly find a free block of size of zval or of size of Hashtable. These macros try to find such free block for given small size (first one) or for the rest of blocks (i.e. bigger blocks which share one free list). -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Quick Question About Git Migration
Hey guys, Please forgive me if this has already been addressed elsewhere, but what can we expect to happen with regard to migrating Subversion credentials over to Git? I.e. how/when will that happen, or has it already happened? Thanks! --Kris
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
2012/3/2 Johannes Schlüter johan...@schlueters.de: So to sum it all up: I would prefer to promise security fixes only to the outside (2 years if people here think that's a good time) and then, as a group, agree to do additional bug fixing during that time. So, to sum it one step further, option #1 -- 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] Quick Question About Git Migration
On Fri, Mar 2, 2012 at 8:11 PM, Kris Craig kris.cr...@gmail.com wrote: Hey guys, Please forgive me if this has already been addressed elsewhere, but what can we expect to happen with regard to migrating Subversion credentials over to Git? I.e. how/when will that happen, or has it already happened? Thanks! --Kris it already happened. you can use your php.net credentials to push through HTTP via digest auth, or you can use your credentials to log in to master.php.net and paste your ssh pubkey to your profile, then you can also push through ssh. see https://wiki.php.net/rfc/DVCS and https://wiki.php.net/vcs/gitfaq and the previous status reports of the dvcs migration from dsp on the list. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Quick Question About Git Migration
it already happened. Not for all projects. how/when will that happen You can see what projects already moved on git.php.net With regards, Alexander Moskaliov ir...@irker.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEADS UP: 5.4 branch is open again
On Fri, Mar 2, 2012 at 11:05 AM, Pierre Joye pierre@gmail.com wrote: that's totally off topic... but we have no idea yet when will be php 6, or whatsoever. However next is in around a year :) PHPME, PHPXP, PHP Feisty Foxbat, PHP# Let's name this bike shed*! -Ronabop *http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Quick Question About Git Migration
On Fri, Mar 2, 2012 at 8:25 PM, Alexander Moskaliov ir...@irker.net wrote: it already happened. Not for all projects. the question wasn't about whether all projects are moved or not. but that the credentials are migrated or not. at least this is what I understood from the original question. for that question, the answer is yes: git.php.net is able to use the same user credentials as svn.php.net, and also fetches the acls from the same global_avail file. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Quick Question About Git Migration
Awesome, thanks for the info guys! Does anybody know what the timeline is on having everything ported over to Git? --Kris On Fri, Mar 2, 2012 at 11:33 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Fri, Mar 2, 2012 at 8:25 PM, Alexander Moskaliov ir...@irker.netwrote: it already happened. Not for all projects. the question wasn't about whether all projects are moved or not. but that the credentials are migrated or not. at least this is what I understood from the original question. for that question, the answer is yes: git.php.net is able to use the same user credentials as svn.php.net, and also fetches the acls from the same global_avail file. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] HEADS UP: 5.4 branch is open again
Actually, my vote would be for PHP Vista --Kris On Fri, Mar 2, 2012 at 11:33 AM, Ronald Chmara rona...@gmail.com wrote: On Fri, Mar 2, 2012 at 11:05 AM, Pierre Joye pierre@gmail.com wrote: that's totally off topic... but we have no idea yet when will be php 6, or whatsoever. However next is in around a year :) PHPME, PHPXP, PHP Feisty Foxbat, PHP# Let's name this bike shed*! -Ronabop *http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality
Re: [PHP-DEV] Quick Question About Git Migration
On Fri, Mar 2, 2012 at 8:34 PM, Kris Craig kris.cr...@gmail.com wrote: Awesome, thanks for the info guys! Does anybody know what the timeline is on having everything ported over to Git? --Kris php-src will be migrated in the next two weeks or so (Stas asked David to wait a little bit, so if something comes up, and we have to do an emergency 5.4.1 release we won't be in-between the migration). my last info was that the documentation will be moved last (after php-src and pecl). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] HEADS UP: 5.4 branch is open again
PHP 6 comes out sometime around 2024 when, at PHP 5.27 Ramus decides to say, screw it - 6. Sorta like what happened with the Linux Kernel (which was 2.26 FOREVER) Tongue in cheek remark aside, we need to be cautious about avoiding using the major version tag (although the stupidity of the browser programming community isn't the way to go either). There are significant differences now between 5.0 and 5.4 functionality, even though the changes between 5.3 and 5.4 are slight - they do add up. Linux fell into this trap - the differences between any two incrementals was tiny, but after 47 of the buggers it was getting ridiculous to say it was still version 2.26.0 compat, which it wasn't. At the end of the day version numbers are perception oriented. If you never move the major number, people will shift perception to the second number being the important one, or in the case of Linux the incremental became the significant one when it shouldn't be. In my opinion, if PHP NEXT has anything - ANYTHING - on par with 5.4 in scope then the distance between it and 5.0 will have become too large to justify calling it a 5.5 and it should be called 6. Fail to do this and the first number will start being ignored by the community at large as superfluous., just as the 2.26 part of the Linux version number had become superfluous before Linux finally bit the bullet and rolled it over. On Fri, Mar 2, 2012 at 2:35 PM, Kris Craig kris.cr...@gmail.com wrote: Actually, my vote would be for PHP Vista --Kris On Fri, Mar 2, 2012 at 11:33 AM, Ronald Chmara rona...@gmail.com wrote: On Fri, Mar 2, 2012 at 11:05 AM, Pierre Joye pierre@gmail.com wrote: that's totally off topic... but we have no idea yet when will be php 6, or whatsoever. However next is in around a year :) PHPME, PHPXP, PHP Feisty Foxbat, PHP# Let's name this bike shed*! -Ronabop *http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEADS UP: 5.4 branch is open again
Hi! I'll work on the patch for strict session patch so that both PHP 5.4 and 5.3 has the same functionality. OK, do you have the latest patch for that? I remember originally it involved some non-BC changes and there were other questions, but I'd like to see the final one. In general, if there's no BC issues, I think it may be OK, but let's see the final patch. I've also added 2 new escape functions to pgsql in trunk a while ago, pg_escape_literal()/pg_escape_identifier(). Is it okay to merge 5.4 branch also? Should be ok, please send me the commit to review. If it doesn't change any structures just adds functions it should be fine. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- 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 Fri, Mar 2, 2012 at 7:51 AM, 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...
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))...
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.
4. What about consistency? Well, there currently is no consistency.
Internal function parameters behave one way, and explicit casts behave
another. And even more confusing implicit casts behave yet another
way ($a + $b). So to implement this, we'd need to be consistent with
one of them. Frankly, I would only want to add consistency to
internal function parameters, since the explicit cast is not useful
IMHO (it's identical to $bar = (int) $bar), at which point it's not
worth adding to save only that one line. But if we're consistent with
internal function parameter checking, then it becomes quite useful.
We can throw warnings on unclean conversion and prevent execution of
the function... That way, all function calls behave the same (as much
as I hate the concept of warnings on type hint failure)... So, in
that case, function calls become an implicit cast to the type, which
is then why the stricter error handling (without breaking the spirit
or consistency).
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.
Thoughts? Should I update the patch to be more inline with what I
said above (the implicit hints that are offered by the current
internal function argument mechanism:
# sapi/cli/php -r 'function foo((int) $bar) { return $bar; } $a = 1;
var_dump(foo($a));'
int(1)
# sapi/cli/php -r 'function foo((int) $bar) { return $bar; } $a =
foo; var_dump(foo($a));'
Warning: Argument 1 passed to foo() must be of the type integer,
string given, called in Command line code on line 1 and defined in
Command line code on line 1
However, since it's not raising a terminating error, more changes
would need to be made to the VM to check the return status of the
argument check (which is currently ignored) to determine if to proceed
with the function call, or just return null imediately...
Thoughts?
Well, this seems like a reasonable approach (at least in terms of general
discussion.)
I would suggest option a), for if it looks like the same type of cast found
within the body of functions. I believe users will expect it to act the
same way, too. Keeping track of two different cast behaviors would add to
the likelihood of misusing one or the other. Additionally, previous
proposals have struggled due to the impedance mismatch perceived between
the proposed hinting solutions and PHP's intrinsic typing qualities.
Keeping things close to the current modus operandus seems like it gives the
proposal more chance of becoming a reality.
I would also suggest that array not be included, if only to limit the scope
of the current proposal and simplify the offering. It could always be added
later. However, if it led to an increased likelihood of being
considered/passed for some reason, then include it :)
Nice work, Anthony.
I am curious what some of the core developers who've been opposed to scalar
type hinting in the past would think of this approach. Zeev, Stas, others,
would this be worth any consideration? It seems like an approach that is
potentially more consistent with PHP's typing mechanisms.
Thoughts?
Adam
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
Hi! Would it be worth while to discuss the possibility of LTS releases (Long Term Support) with 5 or 7 year support (from time of initial release)...? It is fine to discuss it and you can still support PHP 4 now if you want to, but who's going to be doing it otherwise? I wouldn't really want to spend time on fixing 7-year-old PHP version (that'd be like 4.4 now). So we need to approach it with the view of the resources we have. I hope move to Git will make the technical part much easier (merging patches between branches in git is like 2 orders of magnitude faster), but still one has to spend time on backporting, etc. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- 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
Hi! https://wiki.php.net/rfc/php53eol I'm undecided between 1+2 and 2 for both. I guess it depends on adoption of 5.4 and progress with 5.5... Side note: looking at the new email subjects, spent some time wondering why we have this huge thread discussing line endings on the list and what's so special about them in 5.3 :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SVN Account Request: justatest
Someone mentioned having trouble with the form so I#039;m just doing a quick test. Also curious to see where these requests actually go. Please disregard. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: justatest
This was me, please disregard. Someone in our local meetup group mentioned having some problem with the form but it seems to be working just fine as far as I can tell. While I'm thinking about it, who actually approves (i.e. moderates) these requests, anyway? I've always wondered about that. --Kris On Fri, Mar 2, 2012 at 2:41 PM, Test - Please ignore just-a-t...@whatever.com wrote: Someone mentioned having trouble with the form so I#039;m just doing a quick test. Also curious to see where these requests actually go. Please disregard. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: justatest
On Fri, Mar 2, 2012 at 11:44 PM, Kris Craig kris.cr...@gmail.com wrote: This was me, please disregard. Someone in our local meetup group mentioned having some problem with the form but it seems to be working just fine as far as I can tell. we had some problems with the box hosting master.php.net, it caused some ruckus about the account requests, but we sorted that out for like a month now. While I'm thinking about it, who actually approves (i.e. moderates) these requests, anyway? I've always wondered about that. for the svn account requests: http://git.php.net/?p=web/master.git;a=blob;f=manage/users.php#l454 for the pecl account requests it is mostly Pierre (albeit any pecl website admin is able to) -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] HEADS UP: 5.4 branch is open again
Hi Stats The new strict session patch is not ready, yet. I'll prepare path for 5.3/5.4/trunk. I was asked for session id collision detection, so I'll also add that for create_sid() functions. I've also added 2 new escape functions to pgsql in trunk a while ago, pg_escape_literal()/pg_escape_identifier(). Is it okay to merge 5.4 branch also? Should be ok, please send me the commit to review. If it doesn't change any structures just adds functions it should be fine. It just adds new functions. I'll find the commit for review later. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/3/3 Stas Malyshev smalys...@sugarcrm.com: Hi! I'll work on the patch for strict session patch so that both PHP 5.4 and 5.3 has the same functionality. OK, do you have the latest patch for that? I remember originally it involved some non-BC changes and there were other questions, but I'd like to see the final one. In general, if there's no BC issues, I think it may be OK, but let's see the final patch. I've also added 2 new escape functions to pgsql in trunk a while ago, pg_escape_literal()/pg_escape_identifier(). Is it okay to merge 5.4 branch also? Should be ok, please send me the commit to review. If it doesn't change any structures just adds functions it should be fine. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: justatest
Ahh ok that makes sense. I actually didn't realize there was an added admin layer. How was that list generated? --Kris On Fri, Mar 2, 2012 at 3:30 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Fri, Mar 2, 2012 at 11:44 PM, Kris Craig kris.cr...@gmail.com wrote: This was me, please disregard. Someone in our local meetup group mentioned having some problem with the form but it seems to be working just fine as far as I can tell. we had some problems with the box hosting master.php.net, it caused some ruckus about the account requests, but we sorted that out for like a month now. While I'm thinking about it, who actually approves (i.e. moderates) these requests, anyway? I've always wondered about that. for the svn account requests: http://git.php.net/?p=web/master.git;a=blob;f=manage/users.php#l454 for the pecl account requests it is mostly Pierre (albeit any pecl website admin is able to) -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] SVN Account Request: justatest
On Sat, Mar 3, 2012 at 1:56 AM, Kris Craig kris.cr...@gmail.com wrote: Ahh ok that makes sense. I actually didn't realize there was an added admin layer. How was that list generated? --Kris what do you mean by that? from the technical POV? that list is maintained manually. from the policy POV? usually who need access to something and he seems to be trustworthy, he/she gets access. on a related note: http://phpadvent.org/2008/php-meritocracy-by-andrei-zmievski -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] SVN Account Request: justatest
Both. I'd never read anything about that before so was kinda curious how that works given how chaotic the PHP dev process can be at times. I think it's a solid approach but I've always been a fan of having written policies and clear procedures as opposed to the more ad hoc approach that this appears to be. I wouldn't mind seeing this drafted into an RFC; I believe the policy as you described it should remain exactly as it is but the neurotic side of me would be far less antsy if this was clearly articulated in some form of official policy documentation. This is part of my longstanding campaign to ruin other people's Fridays with nitpicky crap. ;P --Kris On Fri, Mar 2, 2012 at 5:30 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Sat, Mar 3, 2012 at 1:56 AM, Kris Craig kris.cr...@gmail.com wrote: Ahh ok that makes sense. I actually didn't realize there was an added admin layer. How was that list generated? --Kris what do you mean by that? from the technical POV? that list is maintained manually. from the policy POV? usually who need access to something and he seems to be trustworthy, he/she gets access. on a related note: http://phpadvent.org/2008/php-meritocracy-by-andrei-zmievski -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
Hey all,
Here's a much more robust and updated patch (actually, it seems good
to go to me, but needs significant review)...
https://gist.github.com/1963999
One potential issue is that it requires an API change to
zend_verify_arg_type (which appears to only be called in zend_vm_def.h
- and by generation zend_vm_execute.h)... Otherwise, it's functional
from my perspective...
Here's what's implemented:
The following cast syntaxes to the parameter type hints:
(int)
(float)
(bool)
(string)
(array)
(object)
Basically, they behave exactly as the normal cast works. So it won't
error except in odd edge cases (for example, passing StdClass object
into (string)...
So, based on that:
function ((int) $i) {}
is identical to:
function ($i) {
$i = (int) $i;
}
Additionally, the last 2 are a bit more interesting, as they will cast
it to an array/object if necessary.
To be honest, I'm not as sold on this version (I built it as a POC,
but to see how useful it is). It feels like it's not doing enough.
All it really does is save 6 characters.
Instead, I think I'd rather see it check for a clean cast, and at
least throw an error on unclean cast (casting (int) foo in this
context). However, that's not how the current cast handler works, so
that's not what this does.
Any feedback?
Thanks,
Anthony
On Fri, Mar 2, 2012 at 3:15 PM, Adam Jon Richardson adamj...@gmail.com wrote:
On Fri, Mar 2, 2012 at 7:51 AM, 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...
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))...
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.
4. What about consistency? Well, there currently is no consistency.
Internal function parameters behave one way, and explicit casts behave
another. And even more confusing implicit casts behave yet another
way ($a + $b). So to implement this, we'd need to be consistent with
one of them. Frankly, I would only want to add consistency to
internal function parameters, since the explicit cast is not useful
IMHO (it's identical to $bar = (int) $bar), at which point it's not
worth adding to save only that one line. But if we're consistent with
internal function parameter checking, then it becomes quite useful.
We can throw warnings on unclean conversion and prevent execution of
the function... That way, all function calls behave the same (as much
as I hate the concept of warnings on type hint failure)... So, in
that case, function calls become an implicit cast to the type, which
is then why the stricter error handling (without breaking the spirit
or consistency).
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.
Thoughts? Should I update the patch to be more inline with what I
said above (the implicit hints that are offered by the current
internal function argument mechanism:
# sapi/cli/php -r 'function foo((int) $bar) { return $bar; } $a = 1;
var_dump(foo($a));'
int(1)
# sapi/cli/php -r 'function foo((int) $bar) { return $bar; } $a =
foo; var_dump(foo($a));'
Warning: Argument 1 passed to foo() must be of the type integer,
string given, called in Command line code on line 1 and defined in
Command line code on line 1
However, since it's not raising a terminating error, more changes
would need to be made to the VM to check the return status of the
argument check (which is currently ignored) to determine if to proceed
with the function call, or just return null imediately...
Thoughts?
Well, this seems like a reasonable approach (at least in terms of general
discussion.)
I would suggest option a), for if it looks like the same type of cast found
within the body of functions. I believe users will expect it to act the same
way, too. Keeping track of two different cast behaviors would add to the
likelihood of misusing one or the other.
