Re: [PHP-DEV] substr/array_slice in []
On Tuesday 02 October 2007, Alexey Zakhlestin wrote: On 10/1/07, Martin Alterisio [EMAIL PROTECTED] wrote: Sorry to bother, I have a few questions on this matter. How will this impact on the SPL ArrayAccess and related interfaces and objects? Will there be an interface to this functionality? If so, how will ranges be passed through to this interface? Will this be consistent with substr() and array_slice() if used with an ArrayAccess implementation? I guess it can be made to work with current ArrayAccess, but result will be quite slow. (it will need to query requested elements one-by-one and recombine those in array) But adding another interface can solve the problem. Ranges can be passed exactly the way they are passed to [] operator public function rangeGet($start, $length); public function rangeSet($start, $length, array $data); Here's the question I see. Right now, does an ArrayAccess object work with array_slice()? If so, then [2, 5] syntax would be just some nice syntactic sugar. If not, then it becomes a powerful new feature, and implementing it on normal arrays and strings becomes just a matter of consistent syntax. Personaly I kinda like it, but I know I'm not the one coding it. :-) -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] substr/array_slice in []
I have no love for Perl (and a rather strong dislike of it), but I have to agree with those who say that looks like Perl is a lame reason to reject something. PHP's object system looks an awful lot like Java, too. That doesn't make it bad. Too unreadable, not approachable enough, too inflexible, etc. are perfectly valid reasons to reject a syntax. Looks like insert language here is not, I content, one of them. On Saturday 06 October 2007, Marcus Boerger wrote: Hello Larry, ArrayAccess is not designed to work in any array functions and we explicitly decided against going that route. We wanted ArrayAccess to support the array syntax, so [x,y] should be supported if we want that. However I agree that this kind of slicing is a bit too perlish or pythonish. marcus Friday, October 5, 2007, 3:05:30 AM, you wrote: On Tuesday 02 October 2007, Alexey Zakhlestin wrote: On 10/1/07, Martin Alterisio [EMAIL PROTECTED] wrote: Sorry to bother, I have a few questions on this matter. How will this impact on the SPL ArrayAccess and related interfaces and objects? Will there be an interface to this functionality? If so, how will ranges be passed through to this interface? Will this be consistent with substr() and array_slice() if used with an ArrayAccess implementation? I guess it can be made to work with current ArrayAccess, but result will be quite slow. (it will need to query requested elements one-by-one and recombine those in array) But adding another interface can solve the problem. Ranges can be passed exactly the way they are passed to [] operator public function rangeGet($start, $length); public function rangeSet($start, $length, array $data); Here's the question I see. Right now, does an ArrayAccess object work with array_slice()? If so, then [2, 5] syntax would be just some nice syntactic sugar. If not, then it becomes a powerful new feature, and implementing it on normal arrays and strings becomes just a matter of consistent syntax. Personaly I kinda like it, but I know I'm not the one coding it. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson Best regards, Marcus -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Strange benchmark behavior
Hi folks. I was hoping that someone here could help me understand a bit of
weirdness I've come across. I'm trying to run some micro-benchmarks on PHP
5's object handling. My test code is as follows:
?php
define('ITERATIONS', 100);
///
echo Testing __call(). PHP_EOL;
class TestCall {
function normal() { return; }
function __call($method, $args) { return; }
}
$t = new TestCall();
$start = microtime(true);
for ($i=0; $i ITERATIONS; ++$i) {
$t-normal();
}
$stop = microtime(true);
echo Native Method: . ($stop - $start) . seconds. PHP_EOL;
$start = microtime(true);
for ($i=0; $i ITERATIONS; ++$i) {
$t-doesntExist();
}
$stop = microtime(true);
echo Magic Method: . ($stop - $start) . seconds. PHP_EOL;
///
echo Testing __call() with sub-function. PHP_EOL;
class TestCallSub {
function normal() { return; }
function bar() { return; }
function __call($method, $args) {
if ($method == 'foo') {
return call_user_func_array(array($this, 'bar'), $args);
}
return;
}
}
$t = new TestCallSub();
$start = microtime(true);
for ($i=0; $i ITERATIONS; ++$i) {
$t-normal();
}
$stop = microtime(true);
echo Native Method: . ($stop - $start) . seconds. PHP_EOL;
$start = microtime(true);
for ($i=0; $i ITERATIONS; ++$i) {
$t-foo();
}
$stop = microtime(true);
echo Magic Method: . ($stop - $start) . seconds. PHP_EOL;
///
?
Basically I'm just trying to figure out the cost of __call() and other fancy
OO features.
The problem I'm running into is that the results I get back on a PHP 5.2.4 box
are along the lines of the following:
Native Method: 0.76211094856262 seconds
Magic Method: 1.851991891861 seconds
Testing __call() with sub-function
Native Method: 1.0601480007172 seconds
Magic Method: 5.7655189037323 seconds
Ignoring the exact numbers for a moment, I am puzzled as to why the second
Native Method is 25% slower than the first. The function call should be
exactly the same. Using a separate variable for the second test had no
effect. My first thought was that the existence of a non-trivial __call()
was slowing down the whole object. However, when I comment out the first
test block entirely, I got the following results:
Testing __call() with sub-function
Native Method: 0.75452494621277 seconds
Magic Method: 6.1330490112305 seconds
So when the first test doesn't get run, the second test gets faster. Huh?
I've run the test numerous times now, and it's very consistent.
Confused, I ran the same test script on a different computer running 5.2.1
(which I have been led to believe is a notably slow and buggy version):
Testing __call()
Native Method: 2.9479010105133 seconds
Magic Method: 5.5952389240265 seconds
Testing __call() with sub-function
Native Method: 2.525377035141 seconds
Magic Method: 11.09939289093 seconds
It doesn't happen there. (Yes, it's a much older box. g) I get almost
exactly the same results for the sub-function version regardless of whether
the first test runs or not, which is what I would expect to happen.
Curiouser and curiouser, I had a friend run the same script on a 5.2.3
computer:
Native Method: 0.976696014404 seconds
Magic Method: 2.29192996025 seconds
Testing __call() with sub-function
Native Method: 0.953128814697 seconds
Magic Method: 4.98710489273 seconds
Again, no statistically significant difference between the first and second
tests.
So I tried it again on another 5.2.4 box, which should be identically
configured to the first. (Two different servers with the same shared hosting
company.)
Testing __call()
Native Method: 0.83786416053772 seconds
Magic Method: 2.7027611732483 seconds
Testing __call() with sub-function
Native Method: 0.94142198562622 seconds
Magic Method: 7.6225128173828 seconds
So, thoroughly confused, I throw the question out. G'What? Is this a bug in
PHP 5.2.4? Is this a flaw in my testing methodology? Is this a flaw in that
one particular server's configuration or compilation? If so to either of the
second two, what?
I'm reluctant to trust any benchmarks from this script until I figure out why
it's behaving like that, so any advise would be appreciated.
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it. -- Thomas
Jefferson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] exception policy for core
On Friday 19 October 2007, Lukas Kahwe Smith wrote: I've actually had issues in the past with PDO and non-exception error-mode handling. I had queries that were running fine but when I checked the error value it gave a non-OK value. (I forget what off hand.) As soon as I switched to exceptions, it worked perfectly. I believe this was under 5.2.1. -- Well that sounds like a bug and not like a feature of exceptions. Or are you implying that the added complexity of this switch makes it harder to write bug free code. I do image that its a bit annoying to have to write tests to cover all the error modes. regards, Lukas I agree, although at the time I wasn't at the point where I could make a viable bug report out of it. I was writing a database wrapper layer around PDO (actually porting PDO into an existing wrapper), and did find in the end that exception-based checking, even though it never left the wrapping function I had around the actual query, made the code a lot nicer to deal with than an if-check in each case. The errors also made more sense, at least to me, than trying to get the error out of the returned error array with a variable number of entries in it. In any case, I don't find the exception usage of PDO to be a bad thing. I agree it should remain possible to use PHP without having dozens of try and catch blocks around everything, but remember that Exceptions are popular exactly because they are a clean and powerful mechanism. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Question about superglobals
As a predecessor of mine at work devised not one but two systems that used global variables as their primary means of internal communication, and I got to sit next to the guy who had to debug and maintain both of them for a year before finally going insane and quitting, I have to agree with Rasmus. Typing global isn't just an extra six characters. It's being polite to the people who will have to maintain your code after you're gone. Undeclared globals are a form of extreme sadism, no matter how much documentation you think you've provided. Declared globals are merely ordinary, run-of-the-mill sadism. :-) I don't see a benefit in the first place. Singletons, collector functions, or as a last resort the global keyword are all viable alternatives. Leave extra superglobals to runkit where such weird edge cases belong. On Friday 16 November 2007, Sam Barrow wrote: I disagree, although you do have a very good point. But simple logic flaws can cause huge bugs regardless, whether it would be because of a superglobal or any other programmer error. Although you have a point, the only place where we disagree is that I think the benefits outweigh the risks. On Fri, 2007-11-16 at 20:34 -0800, Rasmus Lerdorf wrote: Sam Barrow wrote: You say that superglobals were not designed to be user defined, think about it, the concept of a superglobal is present in C and C++, two of the maturest and strictest languages around. The concept of having to declare your globals is unique to PHP, true. It is one of the oldest features in PHP too. So, a little history... Back in 1989 I spent at least a month chasing a bug at a company in Canada called Bell Northern Research. It was a weird crash bug in a rather complicated system. It was mostly written in C and after pouring through reams and reams of code printouts day after day, I finally found that it was due to a side effect of some obscure function overwriting a global variable that was used in a completely different area of the code. That particular feature of the C language was not popular with me for a long time after that, and when it came time to work out function scoping of variables in PHP, I made sure to not make that same mistake. And yes, because PHP is a web language and there are common aspects of a web request that many functions will need to act on, it makes sense to have a finite number of clearly labeled global arrays like _GET, _POST, etc. And later on, being able to access any global via $_GLOBALS was added, but again, it is a very descriptive name and not likely to result in someone mistaking it for something else and ending up with strange side effects. I am definitely not in favor of destroying what I consider a rather good design decision just to avoid a couple of keystrokes here and there. So yes, you will have to keep adding global $cfg; to your functions, or accessing it via $_GLOBALS['cfg'], and when you forget, it won't work. And yes, you will grumble a bit at that, but that is nothing compared to trying to find a bug caused by a global side effect in someone else's code. Trust me, you will grumble a lot more at that. -Rasmus -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Question about superglobals
On Saturday 17 November 2007, Sam Barrow wrote: As i said you guys do have a point. But when you say leave custom superglobals to runkit, you might as well leave them to my patch. You have to specifically declare superglobals, just like in runkit. No difference between this and using runkit except ease of use. Exactly. I don't want it to be easy for incompetent programmers to write code that is physically impossible for me to maintain, because I *will* inherit it and I will lose hair trying to figure out why the frel this variable is doing something weird in random cases. I see it in a similar light as register_globals. Yes, one can write secure code with register_globals on. But it's so much easier to write code that isn't a nightmare to maintain if you start with it off. We should *not* be making it easy for programmers to write unmaintainable code. Writing code that is going to make me want to kill the programmer who wrote it should be difficult, not easy. :-) -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Multiple class inheritance
It sounds like you want to be using decorators instead. http://en.wikipedia.org/wiki/Decorator_pattern On Sunday 18 November 2007, Sam Barrow wrote: What is the general opinion on multiple class inheritance. I have a need for it. I have objects for all user input fields. $username = new field ; $username - name = 'username' ; $username - maxLen = 32 ; I have three types of fields. Fields that are automatically put in the database, such as timestamps, fields that are inputted but not stored, such as confirm password, and fields that are inputted by the user AND stored in the database, such as username and password. Now i have 3 classes: - abstractField (has methods and properties that apply to all fields). - inputField, extends abstractField (has methods and properties for display of input form elements and labels). - dbField, extends abstractField (has methods for storing and retrieving in db, etc.). However for fields that are inputted AND stored in the db, i need to extend both inputField and dbField. - inputDbField extends inputField, dbField. Sure, there may be quick hacks to do this, but the only proper way seems to be to extend both classes, and I don't want to duplicate any code (dbField and inputField are both pretty big, and any modifications will also have to be replicated). And no, I don't want to use interfaces. Interfaces will barely do anything for me, I'll still have to duplicate my method bodies, and properties. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Multiple class inheritance
(Sorry, hit reply too soon.) Or, alternatively, you can mostly implement friend functions of a sort: http://www.garfieldtech.com/blog/php-magic-call but they have a performance penalty: http://www.garfieldtech.com/blog/magic-benchmarks On Sunday 18 November 2007, Sam Barrow wrote: What is the general opinion on multiple class inheritance. I have a need for it. I have objects for all user input fields. $username = new field ; $username - name = 'username' ; $username - maxLen = 32 ; I have three types of fields. Fields that are automatically put in the database, such as timestamps, fields that are inputted but not stored, such as confirm password, and fields that are inputted by the user AND stored in the database, such as username and password. Now i have 3 classes: - abstractField (has methods and properties that apply to all fields). - inputField, extends abstractField (has methods and properties for display of input form elements and labels). - dbField, extends abstractField (has methods for storing and retrieving in db, etc.). However for fields that are inputted AND stored in the db, i need to extend both inputField and dbField. - inputDbField extends inputField, dbField. Sure, there may be quick hacks to do this, but the only proper way seems to be to extend both classes, and I don't want to duplicate any code (dbField and inputField are both pretty big, and any modifications will also have to be replicated). And no, I don't want to use interfaces. Interfaces will barely do anything for me, I'll still have to duplicate my method bodies, and properties. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Multiple class inheritance
On Monday 19 November 2007, Edward Z. Yang wrote:
Larry Garfield wrote:
It sounds like you want to be using decorators instead.
The decorator pattern is inappropriate for this case, because Sam wants
to extend the interface, not change the behavior of an existing one.
class AbstractField {
// ...
}
class InputField {
protected $field;
function __construct($field) {
$this-$field = $field;
}
function __call($method, $args) {
return call_user_func_array(array($this-field, $method), $args);
}
// Other methods.
}
class DBField {
protected $field;
function __construct($field) {
$this-$field = $field;
}
function __call($method, $args) {
return call_user_func_array(array($this-field, $method), $args);
}
// Other methods.
}
$myfield = new InputField(new DBField(new AbstractField(...)));
This is a case where you don't want type-hinting, actually. :-) You could do
the same thing with an AbstractField interface that DBField and InputField
also implement and pass through, which might be faster because you eliminate
the _call()/call_user_func_array() choke point, but it's more code to write.
Pick your poison.
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it. -- Thomas
Jefferson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Question about superglobals
Off the cuff, may have a bug or two, but you get the idea:
function get_config() {
static $config;
if (empty($config)) {
// Something to load the configuration here.
}
$params = func_get_args();
$return = $config;
foreach ($params as $param) {
if (isset($return[$param]) {
$return = $return[$param];
}
else {
trigger_error(...);
}
}
return $return;
}
$bob = get_config('thing', 'silly', 'bob');
No, not as fast as global $config;, but more self-documenting and therefore
easier to maintain and the difference is smaller than the cost of one SQL
query.
Human cycles cost more than CPU cycles.
On Saturday 17 November 2007, Sam Barrow wrote:
Not a bad idea, however in my case (don't know about others) I have very
deep arrays i use for my configuration. This would be more of a pain to
use with these get and set functions. Also, the performance would
probably be worse than just directly accessing the variable.
Good point about not fixing what's not broken, but I think in this
context it couldn't hurt to fix it. I have already fixed it, my patch is
already written and I will continue testing it but I haven't come across
any problems using it.
On Sat, 2007-11-17 at 01:05 -0500, Carl P. Corliss wrote:
Sam Barrow wrote:
Thanks everyone, I knew this, but I didn't want to use runkit because
it is a beta, and i don't want all that other stuff, just superglobals.
Also, runkit only allows you to use php.ini, but my patch allows you to
specify superglobals in your script with the keyword superglobal by
saying:
superglobal $var1, $var2 ;
I don't get why you can't just use a Registry pattern here. Having a
simpleRegistry object that you can throw data into and pull out of not
only allows you to keep your global space clean, but allows you to
encapsulate your global data and access it via a simple interface.
Sure, it might be a few extra keystrokes to type something akin to:
Registry::get('var1'); but, personally, I think the trade-off is well
worth it.
simple example class:
class Registry {
protect function __construct() {} // no instantiation - static class
static protected $data = array();
static public function get($name) {
return (isset(self::$data[$name]) ? self::$data[$name] : null);
}
static public function set($name, value) {
self::$data[$name] = $value;
}
}
summary: why fix what ain't really broke...?
Cheers!,
--
Carl
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it. -- Thomas
Jefferson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internal iteration API
On 7/13/12 12:30 PM, Stas Malyshev wrote: Hi! Yep, today we have : - arrays - Object implementing ArrayAccess - Objects implementing Traversable (Iterator) - array_() functions not working with ArrayAccess' objects - Iterator API not working with arrays (ArrayIterator needed) - ... I forget things There sure is something to do with that to make a consistent API. Definitely, having consistent generic iteration API would be great, and pretty much the only reason many iterative functions don't suport traversables is that there's no such API. As for ArrayAccess, it's more complicated. For example, if you have array_shift() I'm not sure ArrayAccess is enough to implement it. To find out first element you'd need Traversable, but even that won't allow you to shift array elements. So for some array_* functions only thing that you can rely on is an actual array... So, I've not been inside the engine so in practice this may make no sense at all, but what about looking at it the other way around? Vis, instead of making objects more and more like arrays, make arrays an object that happens to implement ArrayAccess, Iterator, and whatever else, with an implementation that matches its current behavior? I mean, it's not like they're actual language arrays now, they're hash maps with a convenient syntax. Then the array_* functions that need to be able to iterate can internally type hint Traversable (and thus take any Traversable, of which a hashmap would be one), those that need to []-access can type hint ArrayAccess, and those that need both can hint, hum, TraversableArrayAccess or something (that extends both of those). Effectively, turn array() and [...] into syntactic sugar on top of a HashMap implements ArrayAccess, Traversable object, much as anonymous functions are, as I understand it, syntactic sugar on top of an object that has an __invoke() method. Combined with the generator proposal and recent improvements to filters, that could lead to some seriously slick potential. $hash_map_of_type_MyIteratableClass = array_map($some_closure, $generator_of_some_sort, 'MyIterableClass'); Would that alleviate the oh god it's two things problem without causing too many other issues? --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internal iteration API
On 07/13/2012 07:35 PM, Stas Malyshev wrote: Hi! So, I've not been inside the engine so in practice this may make no sense at all, but what about looking at it the other way around? Vis, instead of making objects more and more like arrays, make arrays an object that happens to implement ArrayAccess, Iterator, and whatever That'd be very nice idea if we were implementing new PHP. I think the fact that arrays are not objects in PHP is a source of many problems. However, right now it probably won't be possible to do it without breaking BC in many places dealing with array copy/assignment/passing semantics. Hm, valid point. Is there no way that we could setup one object to pass the old way? I suppose that would result in just as many special case exceptions... Perhaps that's a change that could be considered for whatever version does get called PHP 6? PHP 5 changed the passing semantics for objects and we survived that, and it was a big boon to the language. Perhaps that could be rolled into bigger changes later? (There's a PHP 6 thread right now I've not looked at yet...) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make try/catch brackets optinal
On 7/19/12 5:11 AM, Peter Beverloo wrote: I have seen this problem happen, people losing time trying to figure out what is wrong only to find its a missing bracket. As Paul said, this is bug-prone. Other bracket-less blocks allow authors to shoot themselves in the foot equally so, yet PHP supports these as well. The actual problem here is an inconsistency in the parser, which I'd consider to be a bug. Peter PHP doesn't support optional brackets on functions, either; please no one suggest that. Yes, it's inconsistent that some structures allow short-circuited brackets. The solution isn't to let all structures have the bug-attracting syntax. If it wouldn't break a few zillion lines of existing code I'd say we should resolve the inconsistency by making the braces required on if/foreach/etc. PHP only has them optional due to a C/C++ legacy, which may have made sense when the byte size of source code actually mattered for storage efficiency. Yes, I have run into bugs that were caused by people forgetting braces. Yes, I have introduced bugs without realizing it because someone left off a brace and I didn't notice it. Yes, I now always add braces when looking at someone's code; I can't even read it otherwise anymore. Any respectable coding standard requires the otherwise-optional braces. And yes, I always close my /p tags as well, and so should you! :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make try/catch brackets optinal
There is no such thing as an optional closing tag or brace. There's only lazy and sloppy coders, and parsers that encourage them. --Larry Garfield On 7/19/12 10:52 AM, Andrew Faulds wrote: Always close p, but never close li :) On Jul 19, 2012 4:44 PM, Larry Garfield la...@garfieldtech.com wrote: On 7/19/12 5:11 AM, Peter Beverloo wrote: I have seen this problem happen, people losing time trying to figure out what is wrong only to find its a missing bracket. As Paul said, this is bug-prone. Other bracket-less blocks allow authors to shoot themselves in the foot equally so, yet PHP supports these as well. The actual problem here is an inconsistency in the parser, which I'd consider to be a bug. Peter PHP doesn't support optional brackets on functions, either; please no one suggest that. Yes, it's inconsistent that some structures allow short-circuited brackets. The solution isn't to let all structures have the bug-attracting syntax. If it wouldn't break a few zillion lines of existing code I'd say we should resolve the inconsistency by making the braces required on if/foreach/etc. PHP only has them optional due to a C/C++ legacy, which may have made sense when the byte size of source code actually mattered for storage efficiency. Yes, I have run into bugs that were caused by people forgetting braces. Yes, I have introduced bugs without realizing it because someone left off a brace and I didn't notice it. Yes, I now always add braces when looking at someone's code; I can't even read it otherwise anymore. Any respectable coding standard requires the otherwise-optional braces. And yes, I always close my /p tags as well, and so should you! :-) --Larry Garfield -- 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] Internal iteration API
On 07/24/2012 03:52 AM, jpauli wrote: On Sat, Jul 14, 2012 at 2:35 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! So, I've not been inside the engine so in practice this may make no sense at all, but what about looking at it the other way around? Vis, instead of making objects more and more like arrays, make arrays an object that happens to implement ArrayAccess, Iterator, and whatever That'd be very nice idea if we were implementing new PHP. I think the fact that arrays are not objects in PHP is a source of many problems. However, right now it probably won't be possible to do it without breaking BC in many places dealing with array copy/assignment/passing semantics. I'd then say : let's keep that idea somewhere to implement it in a new major PHP version. Anyway, there will come a time where we will be developing for PHP6 (or PHP next Major if you prefer), and I think we should use this gap to break BC and add new cool ideas like this one, we seem all to agree with. Julien.P Agreed. We survived Objects becoming, er, Objects in PHP 5.0. Arrays changing would be a major version change, but if the benefits are enough, we could survive that, too. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates
On 08/01/2012 01:24 PM, Kris Craig wrote: There should be a page like http://www.php.net/ancient-versions listing the versions with the date they went EOL and how much time has passed since them. Some scary warnings about Known remote code execution vulnerabe may be good too. The goal? To serve as single page where you point people when to convince them to upgrade. + =) --Kris Speaking as someone who has to deal with vendors that are still being stubborn about upgrading from PHP 5.2, and who was the lead organizer of the GoPHP5 project years ago, dear god please yes! --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
On 07/27/2012 07:23 AM, Lester Caine wrote:
Nikita Popov wrote:
I'll ask again since no one has answered ...
In a different way ...
Is the only thing that changes the 'function' into a 'generator'
replacing
the call to process the data with 'yield'? ( That would be
'SUSPEND' in an
SQL procedure ) ...
So how DOES an IDE work out the flow in order to correctly check that
variables are defined?
As always, my IDE provides a lot of 'sexy' stuff so that I don't
need to
have it built in to the language, and I still can't see how a lot
of what is
being loaded in helps with performance which is the only thing that
I am
interested in. Performance wise why is yield better than just directly
calling a function to handle the data?
Lester Caine and Alex Aulbach,
may I ask you to continue this discussion in a separate thread? I am
really interested in constructive responses about the generator RFC,
but your discussion is generating a lot of noise, which makes it very
hard for me to pick out the few mails that are of interest to me.
If you could open a new thread (like Generator keyword) it would
help a lot.
Nikita - I am looking for a well reasoned argument as to why generator
has to be added at all! 'Just because it can be' is not a valid
argument, but perhaps you could add to the RFC the performance
implication or advantage of what is being proposed. That would at
least be some comparison with the current methods of doing the same
thing?
Anthony had a very good writeup on generators and how they compare to
iterators last week:
http://blog.ircmaxell.com/2012/07/what-generators-can-do-for-you.html
I think that does a good job of laying out the case for generators as
low-effort iterators.
I still think the syntax feels clunky to me, but that's probably because
I'm not used to it from other languages.
One question, though: It looks based on the voting like finally {}
blocks are going in. So... what should happen in the following situation:
function stuff() {
try {
foreach (range(1, 100) as $i) {
yield $i;
}
}
finally {
print All done;
}
}
Does All done get printed once, or 101 times? Similarly:
function things() {
$i = 1;
try {
while (true) {
yield $i++;
}
}
finally {
print All done;
}
}
That will run indefinitely. So will All done ever print, or does that
finally become unreachable?
(I have no clue what the behavior should be in these cases, just that
it should be sorted out sooner rather than later.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
, but that is, I believe, the question that should inform the rest of these discussions. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration
On 10/26/2012 05:43 AM, Clint Priest wrote:
I'm opening up several new threads to get discussion going on the
remaining being debated categories referenced in this 1.1 - 1.2
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
*Extra shorthand declaration*
Allow extra short declaration of an accessor:
class TimePeriod {
public DateTime $date;
}
/* Would be equivalent to this */
class TimePeriod {
public $date {
get() { return $this-date; }
set(DateTime $value) { $this-date = $value;}
}
}
Thoughts?
My knee-jerk response is that I'd love to be able to do public DateTime
$date; it's nicely self-documenting and gives me very simple type safety
(and therefore a clear and useful error thrown in my face, rather than a
mystery bug later). That said, I think that goes back to my mental
model question in my previous post, and I can't fully endorse this
without knowing my mental model.
--Larry Gafield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
On 10/27/2012 09:38 PM, Larry Garfield wrote: On 10/26/2012 05:37 AM, Clint Priest wrote: I'm opening up several new threads to get discussion going on the remaining being debated categories referenced in this 1.1 - 1.2 change spec: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests Some people are in favor of the internal functions being generated by an accessor declaration should be invisible and non-callable directly. Others are in favor of leaving them visible and callable. *Type 1 ( Userland Programmer )** * As a userland programmer, someone who cares nothing for how php works, only how their own code works. If they define an accessor they expect to see an accessor, reflection should reflect that there are accessors and no other methods they did not explicitly define. If they were to reflect on all of the methods of their class and see a number of __getHours() they may be confused as to why or where this function came from. From their perspective, they have defined an accessor and how that accessor works on the inside is of no importance to them and only seeks to complicate or confuse matters when they are exposed to these implementation details of the php language its-self. If you tried to set a value such as $obj?abc = 1 through an accessor which could not be set, you would probably want to see an error like: Warning, cannot set Class?abc, no setter defined. *Type 2 ( Internals Programmer )** * As an internals programmer, you want nothing hidden from you. If an accessor implements special __getHours() methods to work its magic, then you want to see them, you want to call them directly if you so choose. In effect you want nothing hidden from you. In this case you probably don't even want Reflection to reflect accessors as anything different than specially formatted and called methods on the class. This can be understandable because you want all information available to you. You would probably not be confused if you wrote $obj?abc = 1 and got back an error like Fatal Error: Class-__setAbc() function does not exist. *Unfortunately 80 to 95% of all people who use PHP are of the first type.** * Revealing these internal matters to them would only leave them confused, possibly frustrated and likely asking about it to the internals mailing list to answer (repeatedly). Thoughts? Speaking as a user-land programmer that's been following this thread, but hasn't been able to jump in yet due to the high volume of comments... What's unclear to me is what my mental model should be for this new syntax. That's important for informing how it should be exposed to me. 1) Should I have a mental model of this being some syntax candy on top of existing properties? Vis, this is just a short-hand for bean-style classes? By Bean style, I mean Properties that would be public but aren't because Public Is Bad(tm), so instead we have getX()/setX() for every property, so that we can still use the object like a struct rather than an object but still say we're using methods even though we've just reimplemented public properties with more verbose syntax. (Note: Yes, I know that's a rather harsh and judgmental description. I happen to firmly dislike Bean-style objects.) 2) Should I have a mental model that these fancy-pants properties are some different third thingie on objects, distinct from traditional data members and methods? Right now I'm not sure which mental model I'm supposed to use, and I get the sense that there's no clear consensus on that question yet. That, I think, is the key question, and will inform how things like Reflection should expose data about this new syntax. For instance, if model 2 is how I'm supposed to be thinking, then I'd expect I'd need a third reflection object for getting things off of an object/class, separate from traditional data members and methods. Then it's consistently a third thingie. If, however, I'm supposed to think of it as just a short-hand syntax for writing a bean, then I'd expect it to be presented to me as if I'd hand-written all of the stuff that this syntax is emulating. Vis, methods show up as methods, and anything I'd be able to read/write directly without going through an intermediary method should show up as a property just as it does now. Note: I'm speaking here of the mental model of the user, which does not necessarily have any relationship to the implementation details. If I'm supposed to think of it as a third thingie, it doesn't matter that it may be implemented internally as syntactic sugar. It should be presented to me as a third thingie, consistently, with the engine internal implementation details completely irrelevant. (Which means they can be changed later if needs be.) I don't know which mental
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
See, I'm not convinced that everyone would agree that #1 [just some
syntax candy] is definitely not right. From the discussion here, it
seems like some are still thinking of it that way.
If they are supposed to be a 3rd thingie, and the only relation to data
members as we've known them is that they have the same external syntax,
then IMO we should make them as distinct as possible, everywhere. New
keyword, separate reflection pipeline, the works. That then means that
the implementation detail of public $baz { get() {return 'meep'; }
causes the creation of public function __get_property_meep() should not
be exposed, anywhere, and that method should not show up in reflection,
since it doesn't really exist, it's just an implementation detail.
It's the depending on how you look at it, you may or may not get to see
implementation details leak problem that I think is the worst case
scenario.
--Larry Garfield
On 10/27/2012 10:59 PM, Clint Priest wrote:
Hey Larry,
Glad you chimed in here on this. I my opinion (author of thingy),
they are separate and distinct from data members. More specifically
they are getter and setter code that is called when the property is
accessed.
Using your example:
echo $obj-baz; // executes the code return $this-baz;
and
$obj-baz = 4; // executes the code $this-baz = $value;
So from the perspective of the user of the class, they are just
properties but internal to the class they are implemented with
methods and code.
I think everyone would agree that your #1 is definitely not right,
however I believe there is not consensus on whether or not these *are*
different from properties. To the consumer of the class, they are no
different than properties, to the author of the class they are very
different.
On Saturday, October 27, 2012 9:48:12 PM, Larry Garfield wrote:
On 10/27/2012 09:38 PM, Larry Garfield wrote:
On 10/26/2012 05:37 AM, Clint Priest wrote:
I'm opening up several new threads to get discussion going on the
remaining being debated categories referenced in this 1.1 - 1.2
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
Some people are in favor of the internal functions being generated
by an accessor declaration should be invisible and non-callable
directly. Others are in favor of leaving them visible and callable.
*Type 1 ( Userland Programmer )**
*
As a userland programmer, someone who cares nothing for how php
works, only how their own code works. If they define an accessor
they expect to see an accessor, reflection should reflect that there
are accessors and no other methods they did not explicitly define.
If they were to reflect on all of the methods of their class and see
a number of __getHours() they may be confused as to why or where
this function came from. From their perspective, they have defined
an accessor and how that accessor works on the inside is of no
importance to them and only seeks to complicate or confuse matters
when they are exposed to these implementation details of the php
language its-self. If you tried to set a value such as $obj?abc = 1
through an accessor which could not be set, you would probably want
to see an error like: Warning, cannot set Class?abc, no setter
defined.
*Type 2 ( Internals Programmer )**
*
As an internals programmer, you want nothing hidden from you. If an
accessor implements special __getHours() methods to work its magic,
then you want to see them, you want to call them directly if you so
choose. In effect you want nothing hidden from you. In this case you
probably don't even want Reflection to reflect accessors as anything
different than specially formatted and called methods on the class.
This can be understandable because you want all information
available to you. You would probably not be confused if you wrote
$obj?abc = 1 and got back an error like Fatal Error:
Class-__setAbc() function does not exist.
*Unfortunately 80 to 95% of all people who use PHP are of the first
type.**
*
Revealing these internal matters to them would only leave them
confused, possibly frustrated and likely asking about it to the
internals mailing list to answer (repeatedly).
Thoughts?
Speaking as a user-land programmer that's been following this thread,
but hasn't been able to jump in yet due to the high volume of
comments...
What's unclear to me is what my mental model should be for this new
syntax. That's important for informing how it should be exposed to me.
1) Should I have a mental model of this being some syntax candy on
top of existing properties? Vis, this is just a short-hand for
bean-style classes? By Bean style, I mean Properties that would be
public but aren't because Public Is Bad(tm), so instead we have
getX()/setX() for every property, so that we can still use the object
like
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
There are still use cases for __get(), when the list of internal properties is dynamic. We're actually leveraging that for Drupal 8's entity system. Removing it would be a big problem. :-) But that still doesn't resolve the mental model question. --Larry Garfield On 10/30/12 3:05 AM, Ferenc Kovacs wrote: I would say that the proposed accessors is what we should have added back then instead of __get/__set . The problem is that now we will have two similar (albeit one is an ugly subset of the other) feature which needs to co-exists. My gut tells me that we should ditch the magic method approach with the introduction of accessors and provide easy/automated migration. Ofc. that would mean that we need at least one major version. My two cents from the sidelines. 2012.10.28. 3:39, Larry Garfield la...@garfieldtech.com ezt Ãrta: On 10/26/2012 05:37 AM, Clint Priest wrote: I'm opening up several new threads to get discussion going on the remaining being debated categories referenced in this 1.1 - 1.2 change spec: https://wiki.php.net/rfc/**propertygetsetsyntax-as-** implemented/change-requestshttps://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests --**--** Some people are in favor of the internal functions being generated by an accessor declaration should be invisible and non-callable directly. Others are in favor of leaving them visible and callable. *Type 1 ( Userland Programmer )** * As a userland programmer, someone who cares nothing for how php works, only how their own code works. If they define an accessor they expect to see an accessor, reflection should reflect that there are accessors and no other methods they did not explicitly define. If they were to reflect on all of the methods of their class and see a number of __getHours() they may be confused as to why or where this function came from. From their perspective, they have defined an accessor and how that accessor works on the inside is of no importance to them and only seeks to complicate or confuse matters when they are exposed to these implementation details of the php language its-self. If you tried to set a value such as $obj?abc = 1 through an accessor which could not be set, you would probably want to see an error like: Warning, cannot set Class?abc, no setter defined. *Type 2 ( Internals Programmer )** * As an internals programmer, you want nothing hidden from you. If an accessor implements special __getHours() methods to work its magic, then you want to see them, you want to call them directly if you so choose. In effect you want nothing hidden from you. In this case you probably don't even want Reflection to reflect accessors as anything different than specially formatted and called methods on the class. This can be understandable because you want all information available to you. You would probably not be confused if you wrote $obj?abc = 1 and got back an error like Fatal Error: Class-__setAbc() function does not exist. *Unfortunately 80 to 95% of all people who use PHP are of the first type.** * Revealing these internal matters to them would only leave them confused, possibly frustrated and likely asking about it to the internals mailing list to answer (repeatedly). --**--** Thoughts? Speaking as a user-land programmer that's been following this thread, but hasn't been able to jump in yet due to the high volume of comments... What's unclear to me is what my mental model should be for this new syntax. That's important for informing how it should be exposed to me. 1) Should I have a mental model of this being some syntax candy on top of existing properties? Vis, this is just a short-hand for bean-style classes? By Bean style, I mean Properties that would be public but aren't because Public Is Bad(tm), so instead we have getX()/setX() for every property, so that we can still use the object like a struct rather than an object but still say we're using methods even though we've just reimplemented public properties with more verbose syntax. (Note: Yes, I know that's a rather harsh and judgmental description. I happen to firmly dislike Bean-style objects.) 2) Should I have a mental model that these fancy-pants properties are some different third thingie on objects, distinct from traditional data members and methods? Right now I'm not sure which mental model I'm supposed to use, and I get the sense that there's no clear consensus on that question yet. That, I think, is the key question, and will inform how things like Reflection should expose data about this new syntax. For instance, if model 2 is how I'm supposed to be thinking, then I'd expect I'd need a third reflection object for getting things off of an object/class, separate from traditional data members and methods. Then it's consistently a third thingie. If, however, I'm supposed to think
Re: [PHP-DEV] [RFC] Implement a LoggerInterface to PHP
On 11/08/2012 08:42 AM, Anthony Ferrara wrote: Sebastian, There are already discussing this (to be honest: For months now). Some are mentioned at the pull requests at https://github.com/php-fig/fig-standards/pulls So then there's really no reason to be discussing it for core, is there? There is not. This is a task for the FIG group, not Internals. --Larry Garfield, Drupal rep to the FIG group -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
On 12/10/12 8:32 AM, Johannes Schlüter wrote: Hi, On Mon, 2012-12-10 at 14:10 +0100, Pierre Joye wrote: There was no consensus, I am not sure where you get the idea. By spending the time to go through the thread, taking the opinions stated there, filtering out side discussions (like LTS based release models etc) evaluating it (partly subjective) and summarizing it as in the mail starting this thread. However, we discussed to wait a bit before proposing the RFC to clearly and cleanly define the EOL of 5.3. Your message saying 5.4 was released on March, 1st. That's why I asked this question now while it should have been done before. which is one of the last from the thread doesnt' sound like delaying for additional 3/4 years for a decision. I will clean up this RFC and call for vote later this week (most likely tomorrow). It is very important to follow this step instead of simply say, hey, I will go down this way because I like it ;-) feel free to do what you want. The delay is way too short for 3rd parties to adapt. If people can provide reasons to extend it I'm open to hear those. johannes As a data point, Drupal 8 is slated to target PHP 5.3. Probably 5.3.10 and up, with release targeted in the second half of 2013. That is based primarily on our investigation into what is actually shipping in Linux distributions, and what the market looks like it will probably look like. There's still plenty of places deploying Drupal on PHP 5.2, even though I try to avoid using them myself, including large enterprise hosting services. (I'd love to be pushing to PHP 5.4 faster, but the lag time for distributions and hosts is painful.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extension for str_replace / preg_replace with arrays
On 12/18/12 7:44 AM, Leigh wrote:
On 18 December 2012 13:24, Stefan Neufeind neufe...@php.net wrote:
Since we already have functionality for replacing with arrays in place,
I wondered if giving it one string to replace and then an array to
choose the replacement from (rotating) would be an option. Currently
that's unsupported (either two strings or two arrays).
It's certainly possible to implement, but personally it feels like odd
behaviour. I don't know what other people think about it.
I think you could use a callback-function but would need to add quite a
few more lines to initialise your array first, do a next() on the
array inside the callback-function and (how would you pass it that
array?) and still would have to handle starting from beginning of the
array again once you reach the end etc.
You pass the array using use. You could do it something like this:
$replacements = array(
'one', 'two', 'three'
);
$result = preg_replace_callback(
'/word/',
function($matches) use ($replacements) {
$current = current($replacements);
next($replacements) || reset($replacements);
return $current;
},
'word word word word word'
);
var_dump($result);
Output:
string(21) one two three one two
You could likely simplify the code even further using an infinite iterator:
http://us1.php.net/infiniteiterator
$result = preg_replace_callback(
'/word/',
function($matches) use ($replacements_iterator) {
return $replacements-next();
},
'word word word word word'
);
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
I've seen DateTimeValue used elsewhere for userspace immutable date time objects. Whether that indicates we SHOULD or SHOULD NOT use that for an in-C version, I don't know. (I'm inclined to say should-but-namespace, but I don't know if we're doing that yet.) Of course, I have no idea if anyone in userspace is using DateTimeImmutable... --Larry Garfield On 12/17/12 2:52 PM, Lars Strojny wrote: Hi Derick, I would go with DateTimeValue or DateTimeImmutable as well. Am 17.12.2012 um 19:42 schrieb Benjamin Eberlei kont...@beberlei.de: On Mon, Dec 17, 2012 at 5:48 PM, Derick Rethans der...@php.net wrote: I went for DateTimePoint. Point as in Point in time. I am not too happy with the name, but I think it works better than DateTimeImmutable as that just sounds quircky. I'm still fixing up a few things and adding some test cases. I think I need to make it work with DatePeriod too - but I haven't looked at that yet. some suggestions: DateTimeValue DateTimeImmutable DateImmutable DateFixed DateStatic (and as a bonus: DateTime2) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extension for str_replace / preg_replace with arrays
On 12/19/12 10:30 PM, Christopher Jones wrote:
On 12/19/2012 03:18 PM, Larry Garfield wrote:
You could likely simplify the code even further using an infinite
iterator:
http://us1.php.net/infiniteiterator
$result = preg_replace_callback(
'/word/',
function($matches) use ($replacements_iterator) {
return $replacements-next();
},
'word word word word word'
);
--Larry Garfield
What am I missing that causes the first call to
$replacements_iterator-current() to return NULL
unless the iterator is rewound before use?
Eh, nothing. You're right, next() doesn't return an element, it just
advances, so you still need the current() call. Which seems kinda silly
to me, but whatev.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] - True Annotations
On 1/9/13 9:31 AM, Levi Morrison wrote:
they are nearly syntactically identical to executable code.
nearly is the keyword there. They lack the ending semi-colon. Sure,
this might mean PHP has to actually use an abstract syntax tree, but
that's long overdue in my opinion. I know others disagree. This is
only tangentially related, so I won't say more.
Even if the parser is adjusted to cope with that, it's still an
extremely subtle difference for developers to keep track of. Consider
the following procedural snippets:
@Foo[narf]
function something($narf) {}
@Foo[narf];
function something($narf) {}
The first one says that $narf should pass @Foo validation.
The second one says to call the function Foo with the string constant
narf, and then define a function called something().
That's the sort of subtle bug that's just begging for someone to make an
honest typo and spend the next 6 hours tracking it down, until he
realizes what he did and proceeds to bang his head against his desk in
frustration for missing such a simple error.
Let's not subsidize the headache drug manufacturers with PHP syntax
decisions. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] - True Annotations
Before we all bikeshed on the syntax, shouldn't we be figuring out the feature-set first? Over in PHP-FIG, we've found it useful to audit the existing market to see what's in use. That doesn't dictate decisions we make, but it can be instructional. Eg, if we find that most annotation-using projects out there currently support and use arrays in annotations, then any core implementation really needs to support that as well in order to be a reasonable replacement. Maybe not in the same way, but feature-parity with the current market is the bare-minimum for any such core feature to be successful. It could certainly go farther, but it cannot go less-far. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision
On 1/9/13 12:09 PM, Rasmus Lerdorf wrote: On 01/09/2013 09:45 AM, Anthony Ferrara wrote: PHP NEEDS a vision. It needs something to guide development. Not everyone will agree with it. And that's the point. It levels the playing field for contributions and discussions. Rather than every developer playing for themselves and saying I hope this never happens, it puts it in the context of I don't believe this fits our vision. Note the difference in tone between them. The vision has been the same for years. A general purpose scripting language with a focus on web development. You are simply saying you want the vision to be more specific than that because everyone has a different view of what web development means. But even if we narrow the vision, it will still be open to a lot interpretation. We try to strike a balance between the different and changing views of web development the same way we strike a balance between appealing to weekend warriors and top-100 trafficed sites. No vision statement is going to answer the question of whether annotations should be in docblocks or in the core language. That's simply not what vision statements do. -Rasmus Sure. A vision statement won't say annotations FTW or Objects FTL. But it provides a soft metric and rough target toward which to keep moving, and we can all subjectively measure proposals against that metric, rather than subjectively against our own personal metrics. As a former member of the Board of Directors for the Drupal Association, I feel having a formal visioning process is one of the best things we ever did. +1 to Anthony on needing an actual publicly-documented vision for the PHP project. Even if it doesn't have a BDFL, having some clear standard against which we measure the essence of proposals would be beneficial. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision
On 1/9/13 1:55 PM, Clint Priest wrote: Just a thought here, but perhaps what PHP needs now is a working group that works together to do some basic management of PHP as a language, take into account what the users are wanting, talking about, requesting and setting a vision and direction and make plans for what will and won't and when. In short I think PHP lacks direction because everyone has a voice and nobody has authority. In the last two years of working on property accessors I think I have found this to be the most dis-tasteful aspect of working on the project, no person, document or group that leads. Relevant: http://www.jofreeman.com/joreen/tyranny.htm --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting periods
On 01/28/2013 08:54 PM, Ryan McCue wrote: Zeev Suraski wrote: The vast majority of the PHP community is a silent one; These people don't participate here on internals; They don't attend conferences; They use it - the vast majority of them in a professional manner - and they picked it because they like it the way it is, not because of what it needs to become. For every person that subscribes to internals, there's a thousand (yes, a THOUSAND) people who don't (it's several thousands vs.~5 million). In fact, they're not completely silent. They speak in volumes - PHP 5.4 is used in less than 1% of the sites using PHP today, and even the relatively revolutionary 5.3 is still a lot less popular than 5.2. The new shiny features are not all that interesting for most people. I'd like to speak to this as someone involved in WordPress development. As a whole, despite being a huge project with large amounts of developers and users, WordPress is pretty under-represented on php-internals. One of the big reasons for that is that we're stuck with a lot of backwards compatibility, both internal and external. We try hard to ensure that our API to our plugins doesn't break, which unfortunately has left us with being the go-to project for pointing out bad code. As much as some may want us to, we're not going to go and rewrite WP in a day to use new features, so internals discussions aren't that important at the moment. We're also stuck with a huge number of hosts still on PHP 5.2: http://wordpress.org/about/stats/ I'd say it's somewhat of a chicken-and-egg problem, in that WP can't develop for what's not there, and hosts won't bother upgrading if they don't have to. We only stopped supporting PHP 4.x when the usage dropped below 10%, and I'd see the same occurring for 5.2. Hi Ryan. While I understand that level of conservatism, I think it is somewhat unfounded. The PHP community at large decided to deprecate PHP 4 en masse, and put hosts on notice. It worked, too. The GoPHP5 project included over 100 projects and 200 hosts that collectively decided it was time to kill off PHP 4 and move to PHP 5.2. That launched before the PHP Internals team decided to deprecate PHP 4 [1] , and had been in the works for a few months prior. And that was even without the support of heavyweight Wordpress. If Wordpress announced that it was going to start requiring PHP 5.3 as of some date 6+ months in the future (and there are advantages to doing so that don't require major BC breaking rewrites), I think you'd see a rather significant abandonment of PHP 5.2 among hosts. Many other major projects already have. I would be rather surprised if Drupal 9 doesn't require PHP 5.4. (Drupal 8, currently in development, is very solidly PHP 5.3.) My point being, the chicken-and-egg problem IS resolvable. PHP userland developers do have that power if wielded correctly. We just need to wield it together. We shouldn't let ourselves be pushed around by cheapskate fly-by-night hosts again. Disclaimer: Yes, I was the lead organizer of GoPHP5, but not the sole supporter. [1] Internals started discussing killing off PHP 4 about a week after GoPHP5 launched back in 2007. Whether it was entirely coincidental or there was some causal relationship there is, I suppose, a mystery for the ages. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting periods
On 01/29/2013 01:30 AM, Ryan McCue wrote: If Wordpress announced that it was going to start requiring PHP 5.3 as of some date 6+ months in the future (and there are advantages to doing so that don't require major BC breaking rewrites), I think you'd see a rather significant abandonment of PHP 5.2 among hosts. Many other major projects already have. I would be rather surprised if Drupal 9 doesn't require PHP 5.4. (Drupal 8, currently in development, is very solidly PHP 5.3.) Here's hoping that Drupal can lead that push with the major hosts. 5.2 on 66% of hosts is ridiculous, and I'm personally sick of having to backport things to 5.2. GoPHP5 was a *fantastic* effort and benefited WP immensely even if we weren't directly involved. It's great to hear you say that, given that the messaging coming out of WP at the time was rather hostile. :-) Most of the WordPress committers don't see much advantage with pushing to 5.3 though, so it's doubtful that we'll lead that charge. (Late static binding is probably the only thing that they would see as useful, but WP doesn't use many static methods.) I don't know much if anything about WP internals, but in my experience with Drupal 8 LSB is about the only 5.3 feature that hasn't mattered to us. Namespaces/PSR-0 and closures have been very helpful. LSB not so much, but then I'm pleased to say we have very little static method use in the first place. This all said, the internal dynamics of the WordPress core developers are always changing, and views are definitely becoming less conservative. I don't think you'll see us targeting 5.4 any time soon, but 5.3 is a possibility. I've been talking to a few contacts from the big hosts in the WP space and it seems like they've all got 5.3 upgrading in the pipeline. Maybe next year it will be time for a GoPHP5.5 project. :-) Hopefully by then WP will have become less conservative enough to join the effort. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting periods
On 1/29/13 5:08 AM, Pierre Joye wrote: hi Jan, On Tue, Jan 29, 2013 at 11:55 AM, Jan Ehrhardt php...@ehrhardt.nl wrote: Hi Pierre, Pierre Joye in php.internals (Tue, 29 Jan 2013 05:55:27 +0100): This is one of the reason why the 'new' release process RFC does not allow BC breaks. But we can't be 100% sure that we do not introduce one without you, all projects and users, doing intensive testing using your apps, modules, plugins, etc. And before the final releases, not after. Question: Did you test D7/8 and their respective plugins with php 5.5? No. Reality: many Drupal users are beginning to move from Drupal 6 to Drupal 7 at the moment. So are we. The code freeze for Drupal 8 will be no sooner than July this year. And we have enough issues with D7 under PHP 5.4 to worry about BC breaks beyond PHP 5.4. What do you need to get D7 tested under 5.5? I mean once you have a CI in place, it is not hard to setup one instance to test 5.5. Waiting the final release of 5.5 won't be of any help, not for Drupal, not for us. Clear, detailed instructions aimed at someone who has *never used a C compiler before*[1] for how to build, install, and run a 5.5 alpha, for Mac and for common Linuxes[2], that do not require doing screwy things with running multiple web servers on a single OS. In fact, the ideal would be periodically released VirtualBox images with the latest alpha or beta tagged that we can just boot up and run.[3] The first point is, I think, the biggest blocker. Try out the latest PHP and see what breaks is currently a task that roughly 0.1% of PHP developers have the technical ability to even do. Bring that up to 5-10% and we may see a *much* better feedback loop.[4] [1] Really, I can count on one hand the number of Drupal developers who even know C, much less can compile a complex C application. I'm sure you could make all sorts of disparaging comments about Drupal/Drupalers as a result, and you'd be about 1/3 right, but nonetheless that's the situation. [2] Drupal people are about 2/3 Macophiles, 1/3 Linux-istas, and occasionally we let a Windows user in so that we don't look discriminatory. I don't know how that breaks down in other major sub-communities. [3] We have a CI system in place but it's home grown, doesn't have enough human resources maintaining it, and I don't think it supports multiple variants of the PHP environment well. Yes, this is a problem. We're aware of that, but I don't expect it to change soon, unfortunately. [4] As I am not part of that 0.1% I don't have much if any ability to help improve that number, or I would offer to do so. My C-fu is about 8 years old and was limited to Palm OS. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Travis-CI supports 5.5
On 1/29/13 12:31 PM, Steve Clay wrote: On 1/29/13 11:55 AM, Larry Garfield wrote: [3] We have a CI system in place but it's home grown, doesn't have enough human resources maintaining it, and I don't think it supports multiple variants of the PHP environment Dunno if this was mentioned here, but Travis CI added a 5.5 environment a few weeks ago. Spreading the word to projects to add 5.5 to their config files (or just sending a PR) would be a quick way to get a lot of code hitting 5.5. E.g. https://github.com/symfony/symfony/blob/master/.travis.yml @todo https://github.com/zendframework/zf2/blob/master/.travis.yml https://github.com/cakephp/cakephp/blob/master/.travis.yml https://github.com/auraphp/Aura.Web/blob/develop/.travis.yml https://github.com/EllisLab/CodeIgniter/blob/develop/.travis.yml https://github.com/laravel/laravel/blob/master/.travis.yml ... Steve Clay For those projects on GitHub, agreed entirely. Sadly Drupal is not, and Travis doesn't work for non-GitHub projects at all. (We looked into it a while back and concluded it wasn't practical.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting periods
On 1/29/13 11:46 AM, Ralf Lang wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 29.01.2013 18:38, schrieb Pierre Joye: On Tue, Jan 29, 2013 at 6:24 PM, Attila Bukor attila.bu...@gmail.com wrote: I think Ralf's idea is great. A lot of other projects use nightly builds successfully. I don't think a vbox image would be necessary as no-one would use nightly builds on a production environment, It is not about using anything in prod but catch bugs as early as possible in the QA process. I understand that. Automated distribution packaging of wip code is not meant for production but for rapid deployment of clean state test environments. It's similar to a CI suite. If there is enough interest in php snapshots as rpm, I could begin such a setup on monday. If I could run my own VM (that much I can do) and periodically just do apt-get update php-head, that would lower the barrier to testing new versions by several orders of magnitude. (Yeah yeah insert RPM vs. Apt debate here; both are good to have.) That would be *sweet*. +1 --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On 1/29/13 3:47 AM, Martin Keckeis wrote: From the perspective of the end-user this would be really great! If it could really be done in 2 months - wait for it. best regards. Considering the importance of opcode caches to any serious project these days, I'd say a 2 month delay to get an integrated opcode cache working on release day is absolutely worth it. I cannot speak to the relative merits of APC vs. O+, or how reasonable that timeframe is, but if it is an accurate estimate then from a userland perspective it would be a good investment. (The optimize for APC vs. optimize for shared host with no APC debate comes up in Drupal on a regular basis; being able to count on one would allow us to optimize our own code far better.) I entirely appreciate Anthony's concern about rule bending, but I think this is a feature request at a level that such bending can be considered. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting periods
On 01/29/2013 03:12 PM, Rasmus Lerdorf wrote: If I could run my own VM (that much I can do) and periodically just do apt-get update php-head, that would lower the barrier to testing new versions by several orders of magnitude. (Yeah yeah insert RPM vs. Apt debate here; both are good to have.) That would be *sweet*. +1 Is building from git really that much harder? Yes, it takes a little bit of tweaking to get your configure flags right and getting all the right dev versions of the dependencies installed And right there in that sentence you've caused the eyes of all but about 3 people in the entire Drupal developer community to glaze over. That's my point. As soon as you say compiler, most PHP dev's brains shut down. Right or wrong, good or bad, the gulf between PHP developer and C developer is *huge*, and doing anything at all with the PHP engine, including building dev releases yourself, is closer to being a C developer than PHP developer. Even just I keep a little cn script around translates to what's a cn script, and does it have to do with the Chinese locale? for most people. If we want more PHP developers helping with internals, even just by testing things, that is the gulf that needs bridging. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questioning the future of PHP
On 02/03/2013 08:51 PM, Matt Wilson wrote: Hello all. I'd like to start by saying that I am by no means an expert on the subject at hand, and my knowledge is limited to pretty much basic C/C++. I have done little more than patch and write ad hoc extensions for PHP in the past. I'm not looking to criticize so much, as I'm just interested in an honest discussion, for my own sake and understanding. Many years ago I was on this internals list lamenting that PHP lacked namespaces. I was passionate in my conviction that it couldn't be a true language if it lacked them. But it wasn't until they were finally being considered that I realized the one weakness in PHP that prevented a proper namespace system. The autoload problem. Since PHP lacks an inherent style of code importation, it is a decision largely left up to the developer. This of course causes an order of precedence problem. Now, I won't lie, some of my beef with namespaces as they stand is the \. What can I say, I like a certain feng shui in my code. I understand the technical limitations (or at least think I do) and the problem of ambiguity with other operators, however I feel more effort might have been made. If I were to pull some examples out of my ass, and feel free to rebuke me if I'm missing something obvious, [namespace foo.bar] new [foo.bar.SomeClass]() Would that be so hard to distinguish in the parser? If it is, I'd be grateful to know why. Maybe it would work, maybe it wouldn't, I don't know. But that ship sailed a long time ago and it cannot be changed now without breaking a few million lines of code. Please let that issue die. Touching back on what I mentioned earlier about PHP not having an inherent way to load files, and in daily use it's somewhat arbitrary. I share the philosophy that the programmer should tell the code what to do, and not the other way around; however, I think some enforced structure can be good. This is something of a wet dream of mine and one I highly doubt will come true, but to get rid of __autoload (or at least supplant it with a default loader) would be a dream. I think it's something that PHP needs, to complete some one of advances its made in recent years. Thanks, Matt The autoload problem has already been solved by PSR-0. If you're not using it yet, you should. All the cool kids are. http://www.php-fig.org/ If you're using Composer to manage dependencies, it includes a fully capable PSR-0 autoloader that just works, as well as a classmap-based option. If you're not using it yet, you should. All the cool kids are. http://getcomposer.org/ --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] feature request : easy shared memory
On 3/14/13 12:28 PM, Bob Weinand wrote: Am 14.3.2013 um 18:14 schrieb Rasmus Lerdorf ras...@lerdorf.com: On 03/14/2013 09:13 AM, Bob Weinand wrote: And there is no possibility to store the zval as raw binary data like in memory (deep copy?) So that you only have to copy from ram? And replace the pointers to the place in the string? This must be possible I think. And should be faster. shmop has to be opened on every request and only supports strings. APC, memcache,... can only save under serialized form which is slow. APC doesn't serialize most types. Only actual objects need to be serialized because it is the easiest way to fully save and restore objects. eg. calling their __sleep()/__wakeup() magic methods, etc. Arrays are not serialized. -Rasmus Thanks, ..., okay, didn't know that. But even now I am in favor of a new keyword as it will be easier to have a reference to the shared memory (written in and reread from memory when modified) than every time refetching it when the shared memory block may have changed in an other program (what could really reduce race-conditions implicitly as as a developer you may forget to refetch the variable from shared memory). Yes, refetching always is already possible with an userland getter/setter, but I don't think it's best practice to do so in PHP... Bob Weinand Sharing active memory between processes goes against the shared nothing design of PHP. The lack of the feature you're describing is itself a feature. :-) If you had real shared memory, then you're now writing a multi-threaded app. Even if you aren't using threads per se it's the same level of potential for spooky action at a distance. If your problem space really requires that (and there certainly are those that do), Java or NodeJs will suit you better because those are built specifically for a persistent-server model, rather than PHP's shared-nothing design. However, in practice most PHP/web applications don't need that, because HTTP is a stateless request/response system. Shared-nothing more closely models what the actual environment is doing, and can still be very performant as long as you don't do anything naive. If you're doing something stateful like Web Sockets, then you can run PHP as a cli application that is its own persistent server rather than as an Apache add-on. For that, look at Ratchet: http://socketo.me/ --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OPcache optimizer improvement in PHP-5.5?
Speaking as a userspace developer and site admin, I'd be fine with
trading a more expensive compilation for a runtime improvement. Even a
100% increase in compilation time would pay for itself over only a dozen
or so requests (assuming the runtime improvements are non-trivial, too).
Naturally some optimizations are harder to do than others given PHP's
architecture, but trading more expensive compile for cheaper runtime,
even if not a 1:1 trade, would be a win IMO.
--Larry Garfield
On 4/10/13 9:16 AM, Dmitry Stogov wrote:
For now, the optimizations we do are quite chip.
They may increase the compilation time on first request by 2, but on
following requests we will get it back.
Once we come to really expensive optimizations we will do it offline (in
context of a separate process).
Thanks. Dmitry.
On Wed, Apr 10, 2013 at 5:16 PM, Florin Patan florinpa...@gmail.com wrote:
On Wed, Apr 10, 2013 at 4:07 PM, Arvids Godjuks arvids.godj...@gmail.com
wrote:
2013/4/10 Dmitry Stogov dmi...@zend.com
Hi,
Recently, I've found that OPcache optimizer misses a lot of abilities,
because it handles only one op_array at once. So it definitely can't
perform any inter-function optimizations (e.g. inlining).
Actually, it was not very difficult to switch to script at once
approach.
The attached patch demonstrates it and adds per script constants
substitution explained in the following script
?php
define(FOO, 1);
function foo() {
echo FOO . \n; // optimizer will replace it with: echo 1\n;
}
?
Of course, I ran the PHP test suite and it passed all the same tests.
Personally, I think it's safe to include this patch into 5.5 and make a
green light to some other advanced optimizations in 5.5. (e.g.
conversion
INIT_FCALL_BY_NAME into DO_FCALL).
Any thoughts?
Thanks. Dmitry.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
Many obvious optimizations are not used due to the fact, that script
translation into opcode state has to be fast. The nature of PHP dictated
that and this was re-iterated countless times on this mailing list by the
core developers.
To do advanced stuff, you have to create some sort of pre-compile or
storing that compiled code reliably on disk so that if memory cache is
dropped or restart is done, there is no significant preformance hit while
all the code compiles into optimized opcode again.
I would also imagine that good part of the optimizations would require
multiple files to be processed and optimized, but due to dynamic nature
of
the PHP opcode compilation is done on per-file basis, so do the
optimizations.
It's very commendable that you want to push optimizations and stuff, but
there are some fundamental stuff that needs to be cared of to do some
really good stuff.
My 0.02$
Hello,
If applying optimizations in multiple passes would be a problem for
speed, especially on the first request, then maybe a way to solve this
would be to have a configurable variable like: opcache.passes which is
between 1 and 10 (lets say) and then have the engine do something like
this:
- load the file, compile it and apply a first round of 'quick'
optimizations for the first time and mark it as passed once;
- next request, load the compiled version, apply another round of
optimization then mark it as a second pass
- repeat the above step until the optimization passes in the said file
= opcache.passes value
This way only the initial requests will be affected by this but in a
way that the hit on those requests is smaller that applying all the
steps at once.
I'm really not sure if it's that easy to implement but 'on paper' this
could be the way to solve it imho.
What do you think, does it make sense?
Best regards
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan
--
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] Request for comments - new PHP feature: return typing
On 7/11/13 2:56 PM, Florin Patan wrote: We already have a bunch of RFCs about strict typing in PHP: https://wiki.php.net/rfc/typechecking So I personally am not sure we need yet another RFC on the topic - given that we discussed previous ones multiple times. You are right, as part of the moving from gist to RFC I'll try and contact the authors and see if they are still interested in this topic. Friendly recommendation: Keep the RFC and all discussion tightly focused on adding optional return typing for callables, but ONLY for things that are already type hintable as parameters. Trying to expand beyond that will run right smack into the ancient battlefield of strict typing discussions, and the ghosts of brave souls that have fought and died upon it. :-) I'm pretty sure that would kill the proposal in OT chatter. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Choosing a distributed version control system for PHP (or not). Call for Participation.
On 08/07/2011 04:24 PM, Stas Malyshev wrote: Hi! As somebody that have seen reasonably big project switch from SVN to git and worked quite actively with git since then, I think describing my experience might be useful for those that never tried it. 1. git is much better than svn especially as applied to complex projects with multiple participants which need to accept outside patches, maintain multiple branches and port fixes between branches. You never know how much you needed cheap branching/merging until you worked with it some. 2. Switching from svn to git requires one to undergo some mental shift, and for the first couple of weeks you may be confused and somewhat frustrated by too many things that look like but not exactly like the old system. It would appear too complex and unnecessarily complicating workflows. However, as you develop new routines, you'll find out how it makes sense and will become more effective than with svn. Note that git IS much more complex conceptually than SVN and allows to do much more crazy things - including rewriting history in all kinds of weird ways - so while I don't think I had to ask SVN question in forums for years - I still have to google how to do this in git and ask around for some of the more complex things. I think it's still worth it. Don't know if it makes me a fanboy :) 3. Having system like github around it adds a lot - maintaining multiple repositories, forks and pull requests is a real boon. I'm not sure if it would make sense for php, all things considered, but there are very significant benefits of using such a system where many workflows are already built-in. Please note that it's not hg vs git argument as I know very little about hg and have no experience working with it, but I've read what people write about it and I'm sure many of git's strengths are present in hg too. I hope somebody with experience in hg (or both, even better) will voice in. Drupal completed a move from CVS to Git earlier this year, and our experience was similar. There is a mental shift from a centralized VCS to Git, and that is not a small one, but once it's made there is simply no going back. Pretty much everyone agrees that moving to Git was one of the best things we've done in a long time, and not just because we all hated CVS. :-) A previous poster claimed that a DVCS would lead to confusion as to what the canonical repository was. That is, in my experience, a common fear of someone who has not used a DVCS in production. I know, I used to have the same concern about Git before I actually got to use it. Once I got my hands dirty with it, however, I understood what everyone was so excited about. Git is such an amazingly more productive way to work, the documentation is superb, and the workflow so much saner. It's the first VCS I've used where I actually get what is going on internally. A DVCS, properly managed, does not encourage confusion over forks. If anything, if properly used it makes it easier for forks to come back into the fold later if all parties agree to do so. It's really all a win. Our Windows-based developers also have not really had an issue. :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Choosing a distributed version control system for PHP (or not). Call for Participation.
On 08/12/2011 06:26 PM, Lester Caine wrote: Stas Malyshev wrote: That is not how Drupal seems to be using git ... http://drupal.org/node/803746#clone - See 'Creating a Working Branch' I think they're describing local modifications for the Drupal site there, not developing Drupal. Think about it: suppose we have Drupal versions 7.0, 7.1, 7.2. Those will be branches. But if you want to do something into each of them, it won't do for each developer to create a private branch for each of them - the amount of branches will quickly get out of control. That's when you'd need forks. Actually they are talking about developing Drupal ... Once you have finished working on your fix or feature, you’ll need to bring those changes from your topic branch back into the main fooproject branch. Bare in mind that this is more like PEAR code than compiled C code, so the end target is different but the process is what matters. I'm not sure that is the right way to be doing this process, but if it's what is documented? One of the important features of Git (although some might ague that it's a design flaw; I see it as a feature) is that it does not impose a specific workflow on you. There are easily a half dozen good git-based workflows depending on your development model, as well as at least a dozen bad ones. :-) The GitHub model in particular actively encourages forking and no canonical repository. You can know that a given series of repos are cloned from another given repo, but that doesn't intrinsically say which is the canonical repo. You have to just collectively agree on that. That also encourages contribution in one of two ways: 1) Fork, clone your fork to your own computer, make changes, push, file pull request. (Good for one person working but not for open peer review.) 2) Get commit access to the main repository, clone it to your computer, make changes, merge, push. (Good for a small team that allows lots of people to commit to the mainline.) Drupal is still relatively new to Git, and we have a patch-based peer-review culture. For now we're using Git essentially like CVS with fewer bugs. :-) The primary workflow for contribution is: Clone the official repository to your computer, branch, make changes, make a patch out of those, post to the issue queue for review, and the maintainer commits and pushes it to his clone. We want to eventually move to every issue having its own public read/write repository, but we haven't built the infrastructure for that yet. The key point there is that in Drupal, Drupal core and any given module have a very clear official repository with very limited commit access. There's only 2 people with commit access to Drupal itself right now, compared to the 1000+ of PHP. Most modules have one, perhaps two people with commit access. Everything else happens in the issue queues via patches. We do have unofficial repositories that can be used for personal forks a la GitHub, but that's not an official infrastructure-supported feature yet. (Eventually, we hope.) If PHP were to go Git, it would probably want to custom build a server much like Drupal has with its own workflow model. Probably the biggest advantage, though, is the ability to block large commits to mainline until they're approved by the release manager for a given version but without limiting people's ability to experiment. With Git, people can experiment with unofficial, official, quasi-official, or one-off complete repositories before or after making them public, either for review or merging into mainline, and it's all really really easy. Submodules may make sense for PHP/PECL. I'm not sure. That would likely take the form of a series of repositories, one for each PECL module, much the way Drupal has for its modules. Then the PHP core repository would include a submodule reference to the PECL modules that were considered in core at any given time. Moving a module into/out of PHP itself is then just a matter of adding/removing submodule references. (Drupal does not do that currently for its core-packaged modules, but in theory we could.) I do think that Git would be a smart move for PHP; any limitations that the GitHub model imposes are just that, impositions of the GitHub model. There's no reason that Git has to be used in that fashion if some other model would fit PHP better. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Choosing a distributed version control system for PHP - problems
I'd be happy to put people in touch with members of the team that handled the Drupal git migration earlier this year. They successfully migrated 1 million lines of code with a 10 year history across a few thousand repositories from CVS to Git without a hitch (at least no hitch that the outside world saw). That sort of practical experience should be helpful in determining some of the finer points of how you'd actually DO that for a project like PHP. --Larry Garfield On 8/17/11 3:13 AM, Lester Caine wrote: At the risk of being criticised again, I will lay out a couple of problems that need to be addressed as part of making any progress on DVCS support. The first question is 'Do we need DVCS?' The answer is simple - yes - but what and how is not so clear cut. (Bare with me ...) This leads on to 'What is stopping using DVCS currently?' And the answer is in the rfc - We will not convert the whole SVN repository at once. A mirror of the existing SVN repository falls over because of the size. So would it be possible to break down the base into more manageable chunks without moving it to DVCS? Modularize the existing code so that DVCS mirrors are more practical? It is this area that is probably more important to get agreement on than selecting a particular DVCS system. The submodule/subrepo handling process has been relegated to subsequent RFC's, when in reality it is handling this area which is key to getting a fully DVCS based system working at all and how the underlying system handles it needs to be part of the decision process? The other question I think is a no-brainer. 'Where is a DVCS solution hosted?' Choosing a solution simply because github is more popular than bitbucket did annoy me when other projects made it, but in the case of PHP I don't think anybody would suggest that the whole repo system would be moved to one of these? So the master repos would be at dvcs.php.net? That being the case, with the correct modular structure, then people should be able to simply clone to their preferred DVCS system, and commit changes back via karma authentication? I have no doubt that work in progress would then be appearing on bitbucket, github and private hosts, but everybody knows where the master codebase can be found. In hindsight, the SVN move probably took too long to agree on, and developments in other areas were already at that time pressing on that process. But at that time DVCS systems were definitely not ready for handling modular code bases like PHP, and I would argue at the moment that this is still an area that is not totally developed? Simply mirroring CVS to DVCS would probably have been a lot easier process to manage, but we are now 'lumbered' with SVN, so can the SVN experts offer any ideas to creating a path forward? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RESULT] Choosing a distributed version control system for PHP
On 09/07/2011 04:57 PM, David Soria Parra wrote: For everyone else, go read http:/progit.org, make yourself familar with Git. - David The Drupal community has collected various good resources on Git as well: http://drupal.org/node/783086 (You can ignore the Drupal-specific ones, of course.) I can't second Pro Git enough as a fantastic resource. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Time zone database shut down by legal threat
On 10/06/2011 08:53 PM, Chris Stockton wrote: Hello, On Thu, Oct 6, 2011 at 4:45 PM, J. Adamszardozro...@gmail.com wrote: Perhaps we could all contact Astrolabe and voice our complaints? http://alabe.com/ Not sure how copyright can apply to time? If so put me in for copyright on Mondays.. once I own them I can get rid of them forever! But really, I believe the claim seems to have little ground to stand on in. -Chris It doesn't, but under DMCA rules if someone sends you a takedown notice then you're guilty until proven innocent; and if you're an intermediary host, you can make yourself immune to prosecution by taking down an allegedly infringing work immediately, without bothering to check to see if the claim is bogus or not. It's a wonderful world we live in. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader RFC Voting phase
On 11/07/2011 01:42 PM, Ferenc Kovacs wrote: On Mon, Nov 7, 2011 at 7:26 PM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: On 07/11/11 19:17, Lester Caine wrote: guilhermebla...@gmail.com wrote: To participate of php-standards group, feel free to join here: http://groups.google.com/**group/php-standardshttp://groups.google.com/group/php-standards Not while it's not a php list ... +1. It would be great if PHP could host this mailing-list. It would be an act of kindness ;-). The group decided to take off from php.net AFAIK: http://greg.chiaraquartet.net/another-200 The standards group was originally on php.net, and moved off when it was basically thrown off for declaring that they were the self-appointed dictators of what was Correct PHP(tm). After backing down from that, and it was concluded that the group was not an official PHP anything, it was determined that they therefore should not be on php.net. There was a lot of drama around that whole PR fiasco. Since then the group was basically silent for a year and a half, but has recently started to inch back to life and discuss what to do moving forward, and opened the list to public membership. I still think it should remain off-PHP, because it is *not* an official PHP Group blessed committee, but that doesn't mean core devs should not be involved. If anything, the low degree of communication between people who write PHP and people who write in PHP is, and has long been, one of PHP's great weaknesses. I think this entire thread has shown that very well. That is something that needs to be addressed, just as much as inter-framework communication does. Perhaps moreso. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader RFC Voting phase
On 11/10/11 8:19 AM, Pierre Joye wrote: What amazes me is this exact argument. We never had, in the whole PHP history, so many leading projects agreeing on something, together and propose it to the core. I, for one, have been waiting for that to happen for years (PEAR, etc.), and now that it is happening, what do we do? 'No thanks', for whatever reasons. That's so wrong. Actually it's the second. The first big agreement was GoPHP5, which is how we finally buried PHP 4. :-) Sadly that momentum didn't continue (in part my fault). --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On 11/23/2011 12:13 PM, Lester Caine wrote: Richard Quadling wrote: I agree with Daniel on this. Just looking for any test relating to isset() to see what tests will now fail. So it's not just me :) I am seeing this break real world projects and can't see a easy way to fix the break. There is nothing really wrong with the current code except that the sub keys have yet to be populated. This is going to be a huge problem for Drupal. Drupal uses deep associative array structures a lot, by design. That means we isset() or empty() on arrays a lot. I haven't had a chance to test it yet, but I see this change breaking, um, A LOT. And as Daniel noted, the fix is to turn one line of very readable code into 8 lines of hard to read code. This is not a step forward by any metric I can imagine. It's changing long-standing behavior for no real benefit I can see except perhaps strict adherence to a doc page. However, PHP has always been an implementation is the standard language, which means this is a language API change. Please roll it back to avoid breaking a crapton of existing, legitimate, non-buggy code. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Thoughts On Implementing Decorator Sugar to core
, but I could get behind Option 2 as well. Option 1 feels a bit too magic for my tastes. I could live with 1 or 3, but not 2. 3 seems the most robust, but needs some thinking through first. Another thought, should a decorator be able to pass the type hint that the decorated object can pass? For example, should `new MyDecorator(new PDO)` be able to pass `__construct(PDO $pdo);`? If so, how would that be handled? Would the `Decorates` line automagically insert the decorator in the class hiearchy for type checking only? Or is that a bad idea in general (I have a feeling it is)... I'm not sure what you're suggesting here. Are you asking if a class should magically inherit the interfaces of an object it decorates? That's... I don't know if that would work, honestly. :-) It also goes to the inevitable tug-of-war behind being a strict language vs. a dynamic language. What are your thoughts? Anthony Cautiously positive on the concept. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On 11/24/2011 02:58 PM, Ferenc Kovacs wrote:
On Thu, Nov 24, 2011 at 9:12 PM, Larry Garfieldla...@garfieldtech.comwrote:
On 11/23/2011 12:13 PM, Lester Caine wrote:
Richard Quadling wrote:
I agree with Daniel on this.
Just looking for any test relating to isset() to see what tests will
now fail.
So it's not just me :)
I am seeing this break real world projects and can't see a easy way to
fix the break. There is nothing really wrong with the current code
except that the sub keys have yet to be populated.
This is going to be a huge problem for Drupal. Drupal uses deep
associative array structures a lot, by design. That means we isset() or
empty() on arrays a lot. I haven't had a chance to test it yet, but I see
this change breaking, um, A LOT. And as Daniel noted, the fix is to turn
one line of very readable code into 8 lines of hard to read code.
Did you managed to read the whole thread?
I'm asking because there were lot of confusion about the actual impact of
this problem, and Lester particularly seemed confused.
To be fair, no, I hadn't read the whole thread by the time I sent that.
(One of the challenges of long fast-moving threads is they're hard to
keep up with.)
There is nothing really wrong with the current code except that the sub
keys have yet to be populated.
that isn't true, if the array or some sub elements are empty(yet to be
populated), you won't bump into this change. See my previous mail for the
exact details.
so the above mentioned one liner:
if (isset($arr['package']['attribs']['version'])) {
what could go wrong:
$arr is not an array, but a string - it would fatal on 5.3(Fatal: cannot
use string offset as an array), but it would work with 5.4
$arr['package'] is not an array but a string - false on 5.3, true on 5.4
(this is the worst case)
$arr['package']['attribs'] is not an array but a string - true on both 5.3
and 5.4 (so you are already screwed)
So to clarify, what Drupal does on a regular basis is something like:
if (isset($foo['bar']['baz']['beep'])) {
// Assume that bar, baz, and beep all exist, and that beep has a value
}
// or sometimes
if (!empty($foo['bar']['baz']['beep'])) {
// Assume that bar, baz, and beep all exist,
// and that beep has a meaningful value
}
Generally $foo, bar, and baz will all be arrays, and if they're not it
means someone else had a bug somewhere. Of course, Drupal module
developers never have bugs in their code that accidentally puts a string
where they should have put an array, no, not at all. :-) (Generally
when that happens we already hit a first argument to foreach() must be
an array error.)
Currently we don't use ArrayAccess anywhere aside from inheriting it
from PDO.
If that doesn't change, then I rescind my previous panic attack.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Autoloader Error Handling
On 11/25/2011 04:21 AM, Sebastian Krebs wrote: 2011/11/25 Ferenc Kovacstyr...@gmail.com The problem with fatal, that you have no way (by the standard means, but you can somehow manage it through the usage of output buffers or register_shutdown_function, but thats ugly, and can change in the future) to intercept and gracefully terminate your application, which is an often needed feature. AFAIK E_FATAL should be only used where the engine is left in an unstable state, which isn't really true here. Trying to interact with a non-existing class is not an unstable state? there are two situations: 1. The application is broken, thus the FATAL is appropriate 2. The application tries to work with dynamic class names. If it doesn't use class_exists() before, its broken and FATAL is appropriate So I think that E_RECOVERABLE_ERROR would be more appropriate here, and in There's a third possibility. 3) The application uses a mapped or indexed autoloader and the map is out of date. Rebuilding the map would resolve the error. So I could see a use for a recovery there; if new NonExistentClass fails, try to rebuild the index and try again before fataling out entirely. Whether that's too much of an edge case or not, I don't know, but it is a legitimate use case. (Drupal 7 has an indexed autoloader, and we've run into the stale index problem many times. We're trying to migrate most code to PSR-0 for Drupal 8, but even that could use an index for caching/performance reasons.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change bug tracker bogus to not-bug?
On 1/24/12 5:47 PM, Ferenc Kovacs wrote: On Wed, Jan 25, 2012 at 12:11 AM, Justin Martinfrozenf...@php.net wrote: Hello, With some frequency, I find bugs which are not bogus, so much as they are reported based on a misunderstanding. Usually this happens for documentation problems, where someone has misunderstood what the documentation says, or hasn't read the documentation thoroughly enough. I'd like to propose simply changing the term bogus to not-bug. This would more politely and clearly indicate the nature of the way the bug is being closed, in addition to the comment that one ordinarily leaves. Those I've spoken to in php.doc agree. Any objections? Thank you, Justin Martin +1 on this. some other alternatives which was proposed in the past: - Not a bug, proposed by Philip and others - NFF/No Fault Found, proposed by RQuadling honorable mentions: - pebkac, doofus, and 'not our problem' from yawk - SEP (Someone else's problem) from cjones I was recently introduced to the concept of the Level 8 error. (Let's see who gets that one...) Anyway, +1 from me as well to friendlier, less accusational issue statuses. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 Benchmarks
Yowza. If I were seeing that kind of memory change in just one project I'd say there was a bug and the code was just dying. :-) What sort of configuration were you using in each case? A 512 KB Drupal process seems, um, low, especially compared to the other projects listed there. (Drupal 7 is normally rather memory hungry.) --Larry Garfield On 2/6/12 1:52 AM, Dmitry Stogov wrote: Hi, I've just rerun some synthetic and real-life benchmarks. All the test were run on the same box (Linux, Core2 Duo 3GHz, 4GB RAM). 5.3 and 5.4 where configured and build with the same options and ran as FastCGI server with the same number of processes and set of extensions. PHP performance [sec] - 5.3 5.4 speedup bench.php 3.21 2.56 20% micro_bench.php 23.15 11.23 50% PHP + Zend OptimizerPlus performance [req/sec] -- 5.3 5.4 speedup blog 62.8 71.0 13% drupal 1074.3 1146.7 7% zend framework 102.9 124.6 21% hello 5955.4 7826.5 31% qdig 267.6 280.4 5% typo3 357.0 405.6 14% wordpress 119.8 130.8 9% xoops 78.4 93.0 19% scrum 96.3 117.4 22% PHP/O+ memory usage (memory_get_peak_usage) [KB] 5.3 5.4 improvement blog 1280 768 40% drupal 512 256 50% zend framework 7680 5888 23% hello 512 256 50% qdig 768 512 33% typo3 1536 1024 33% xoops 1536 1280 17% scrum 1792 1280 19% Thanks. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
On 2/21/12 5:45 PM, Tjerk Meesters wrote: On 22 Feb, 2012, at 2:03 AM, Ralf Langl...@b1-systems.de wrote: I see no reason why it would be not desirable to have PHP raise the exception rather than putting more or less repeating code snippets all around the place. That is why I am asking. You must be returning false/null somewhere. It's the same effor to instead throw an exception or to return a Ghost family member. The $baby-mother() method cannot know if the using code just wants to collect the $mother object or execute code on it. It can also not know if having no $mother is a problem or just a fact to deal with. Unconditionally raising an exception is a bit overkill here, at least if we would get an exception for trying to access (null)-mother(); Currently the user code must check each link of the chain if it is available, although it is only interested if it can get the final result or not. I'll follow the suggestion and write an RFC. You'll have my vote! :) bloating code with chainable checks is just crazy, something that the engine can do much more efficiently and unambiguously. I would also support this. There's a myriad reasons why something may return NULL or FALSE when you expect it to return an object, some of them even legitimate. Any function/method whose documentation line is returns the foo object, or NULL if someone screwed up and there isn't one is perfectly reasonable in many cases, IMO, but makes all chains a potential fatal. An exception would make a lot more sense, and allow us to centralize handling of such exceptional cases rather than throwing if-checks everywhere. (Which is exactly what exceptions are for.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
On 2/22/12 12:37 PM, Peter Lind wrote: I would also support this. There's a myriad reasons why something may return NULL or FALSE when you expect it to return an object, some of them even legitimate. Any function/method whose documentation line is returns the foo object, or NULL if someone screwed up and there isn't one is perfectly reasonable in many cases, IMO, but makes all chains a potential fatal. An exception would make a lot more sense, and allow us to centralize handling of such exceptional cases rather than throwing if-checks everywhere. (Which is exactly what exceptions are for.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Seems to me this change would encourage bad habits (breaking the law of Demeter) which would personally put me against it. Regards Peter How? What bad habit does this encourage? --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On 2/24/12 3:28 PM, Richard Lynch wrote: On Wed, February 22, 2012 9:10 am, Michael Morris wrote: $_REQUEST does nothing of the sort, and it's use is dangerous in RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST and $_COOKIE, in that order but the php.ini directive can change it. Hence there's no way of knowing if $_REQUEST['password'] came from $_COOKIE, $_POST, or $_GET, and worse, if two values in those source arrays have the same key $_REQUEST will overwrite them. $_REQUEST to be honest, is a lame shortcut and bad idea almost on par with register_globals. Given that all three of $_GET $_POST and $_COOKIE are equally suspect from a security POV, and you shouldn't really *care* which way the client delivered the value, or at least not rely on it for anything useful, I've never understood the resistance to using $_REQUEST. Yes, GET should be idempotent, but there are many APIs and functions in a large app that are idempotent by nature, and having a REST that just doesn't care how the data comes in allows the consumer of the service to use whatever they prefer. If your entire REST service is read-only, such as an RSS feed, why not allow GET or POST (or, silly as it may be COOKIE) and just use $_REQUEST. Because GET and POST are not even remotely the same thing and treating them as completely interchangeable is a bug in the first place. It is in fact legal to have both in the same request. Then what do you do? The idea of having a real request object in PHP is a good one; however, a superglobal is not it. Making it a superglobal eliminates the value of a real request object, namely that you can encapsulate it, override it locally, pass it around, mock it for testing, etc. in a safe fashion. A superglobal request object is a complete waste of time. There are a number of existing request object libraries out there already. PECL HTTP in C, both Zend and Symfony2 have their versions, etc. Drupal is in the process of moving to Symfony's. Any PHP-core request object (which in general I will agree is a good thing, and something sorely missing in the language today) should be based on one of those, where there's already existing work done to work out the kinks. Simply throwing $_GET onto a property of a superglobal object does not accomplish anything useful. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On 2/24/12 4:34 PM, Richard Lynch wrote: On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote: On 2/24/12 3:28 PM, Richard Lynch wrote: Because GET and POST are not even remotely the same thing and treating them as completely interchangeable is a bug in the first place. We'll have to agree to disagree here. To me, it's just a request for some content, and in a REST API that's read-only, I just don't care if the consumer sends their request as GET or POST. I'll cheerfully give them what they wanted. Except that per HTTP, GET and POST are completely different operations. One is idempotent and cacheable, the other is not idempotent and not cacheable. I very much care which someone is using. As Will said in the other reply, there's security implications. (I don't know who suggested that POST is more secure than GET. I certainly didn't.) You want your login form operating over POST, not GET, in large part for the reasons above. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On 2/24/12 4:48 PM, Ronald Chmara wrote: On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfieldla...@garfieldtech.com wrote: To me, it's just a request for some content, and in a REST API that's read-only, I just don't care if the consumer sends their request as GET or POST. I'll cheerfully give them what they wanted. Except that per HTTP, GET and POST are completely different operations. One is idempotent and cacheable, the other is not idempotent and not cacheable. I very much care which someone is using. People exploiting security would *never* think of caching/replaying/modifying a POST request, that's just totally unimaginable! It would take, like HUGE computational effort to like, cURL it or just type it out! er, no. -Ronabop Please point out where I said that POST not a security risk. I am quite sure I typed no such thing, so how you read such a thing I do not know. I am genuinely curious to see how you managed to interpret anything I said as POST is secure because it won't be cached. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On 2/24/12 5:04 PM, Ronald Chmara wrote: On Fri, Feb 24, 2012 at 2:54 PM, Larry Garfieldla...@garfieldtech.com wrote: On 2/24/12 4:48 PM, Ronald Chmara wrote: On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfieldla...@garfieldtech.com Except that per HTTP, GET and POST are completely different operations. One is idempotent and cacheable, the other is not idempotent and not cacheable. I very much care which someone is using. People exploiting security would *never* think of caching/replaying/modifying a POST request, that's just totally unimaginable! It would take, like HUGE computational effort to like, cURL it or just type it out! er, no. Please point out where I said that POST not a security risk. I am quite sure I typed no such thing, so how you read such a thing I do not know. I am genuinely curious to see how you managed to interpret anything I said as POST is secure because it won't be cached. Well, I didn't actually say that you said any such thing. I picked up on: the other is not idempotent and not cacheable ...which is obviously false, and I highlighted, in a security context, how POSTs are cached, and should be treated with equal distrust as GET, because both are suspect, user submitted, forms of data, subject to exploiting. -Ronabop When systems are behaving properly, POST is not cached. I was referring to the RFC: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5 Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource. So strictly speaking its the response to a POST that is not (by default) cached. From a security perspective, yes, all incoming data should be viewed as a threat until proven otherwise, regardless of what part of the HTTP request it comes from or what superglobal PHP marshals it into by default. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On 2/24/12 4:55 PM, Jeremiah Dodds wrote: Except that per HTTP, GET and POST are completely different operations. One is idempotent and cacheable, the other is not idempotent and not cacheable. I very much care which someone is using. Correct me if I'm wrong, but you're referring to the HTTP *method* used. A POST can be made to a URL that includes a query-string, but what that means as far as interpreting the variables is undefined as far as I know. Because of that, I think it's a bad idea to either treat them as the same thing, or rely on both $_POST and $_GET parameters being present. The underlying problem is that HTTP has a URI query string, and a body. In a typical GET request there is no body. In a typical POST the body is a query string in similar format to the URI's query string, plus possibly other stuff. In other request methods the body may be something else entirely. PHP's superglobals make the (wrong) assumption that the URI query string comes from a GET query (hence $_GET) and body comes from a POST query string ($_POST), because that matches up with the default method= attribute of HTML forms. That assumption is limiting and misleading, and made worse by the existence of $_REQUEST, but is the assumption that PHP makes. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
That's going to get turned into the real name if used. I suggest instead: Gribblefritz. Gribble typing: the type handling that PHP does today in 5.3/5.4 for scalar values. Fritz typing: Some as-yet-undefined type handling that is pickier than Gribble typing, but how much pickier is unclear. That, at least, no one has any pre-conceived definition of. --Larry Garfield On 2/27/12 4:31 PM, Kris Craig wrote: Would firm work better? --Kris On Mon, Feb 27, 2012 at 2:27 PM, John Crenshawjohncrens...@priacta.comwrote: -Original Message- From: Kris Craig [mailto:kris.cr...@gmail.com] Now, to rewind a bit past the latest chunk of I hate this idea posts I'd like to suggest a new term: strong. This term would be similar to weak, except with a few key differences: ... Some possible examples of how this would look: weak int $i = aaa; // Converts to 1 and throws a warning. strong int $ii = aaa; // Throws a fatal error. weak int $i = 1; // Converts to 1. strong int $ii = 1; // Converts to 1. --Kris Can we use a different word (not strong) at least for just discussion purposes? I worry that strong will produce a feeling of intense fear and anxiety in people who have been burned out by strict typing debates. The words strong and strict are basically inflammatory at this point. In the interest of facilitating a reasonable discussion, I think we should avoid language that is likely to cause discussion to break down. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] readfile() memory usage
So, I've been reading articles for a decade now that say that readfile() is great and wonderful except for memory usage. Specifically, that it reads a file into memory entirely, and then prints it to stdout from there. So if you're outputing a big file you will hit your memory limit and kill the server. Thus, one should always loop over fread() instead. The most recent article I found saying that was from 2007, with a StackExchange thread saying the same from 2011. I've even found mention of it in old PHP Bugs. However, I cannot replicate that in my own testing. Earlier today I was running some benchmarks of different file streaming techniques in PHP (5.3.6 specifically) and found that fread() looping, fpassthru(), readfile(), and stream_copy_to_stream() perform almost identically on memory, and all are identical on CPU except for fread() which is slower, which makes sense since you're looping in PHP space. What's more, I cranked my memory limit down to 10 MB and then tried streaming a 20 MB file. No change. The PHP peak memory never left around a half-meg or so, most of which I presume is just the Apache/PHP overhead. But it's not actually possible for readfile() to be buffering the whole file into memory before printing and not die if the file is bigger than the memory limit. I verified that the data I'm getting downloaded from the script is correct, and exactly matches the file that it should be streaming. My first thought was that this is yet another case of PHP improving and fixing a long-standing bug, but somehow the rest of the world not knowing about it so conventional wisdom persists long after it's still wise. However, I found no mention of readfile() in the PHP 5 change log[1] at all aside from one note from back in 5.0.0 Beta 1 about improving performance under Windows. (I'm on Linux.) So, what's going on here? Has readfile() been memory-safe for that long without anyone noticing? Is my test completely flawed (although I don't see how since I can verify that the code works as expected)? Something else? Please un-confuse me! (Note: Sending this to internals since this is an engine question, and I am more likely to reach whoever it was that un-sucked readfile() sometime in the silent past that way. g) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] readfile() memory usage
Thanks all. So it sounds like the answer is: 1) readfile() has always been memory-safe as far as PHP is concerned. 2) Because it uses mmap(), GFL trying to understand its memory usage from top. 3) Operating systems have gotten better at such things in the past decade. 4) So given #2 and #3, the readfile() will kill your memory, don't use it line is a persistent urban legend that belongs on Snopes as debunked. Looping on fread() for performance is a red herring. Is that an accurate summary? If so, I will blog my benchmark results and this conversation. --Larry Garfield On 4/30/12 5:33 AM, Sherif Ramadan wrote: Mmapping of course uses memory, but the memory used here is not from PHP's memory manager, it's memory that's already used for the O/S cache. The memory mapping used here does not enforce loading the file contents into O/S cache; it just gets a virtual address into the O/S cache. If the actual file contents are not yet in O/S cache, the O/S will hit a page fault and load the pages into memory. Apache Server uses the same mechanism to serve files. Maybe the user confusion about memory usage comes from that fact (they see lots of *virtual* memory used by PHP when viewed in top). I know this user confusion from my work in the Apache Lucene/Solr project, where one option (used on 64 bit operating systems) is to memory-map the whole Lucene full-text index. Users then see hundreds of Gigabytes of virtual memory usage in TOP / Windows Task Manager and are afraid of running their machine out of memory. This is always hard to explain to people that are not used to the term virtual memory. That's a very good point and a detailed look at the stack can show some of the underlying mechanics coming from readfile and how its pretty much is just implemented like fpassthru delegating a stream, as you said. http://i.imgur.com/PWiTv.png About php memory usage, one has to use an external tools to actually see this memory usage as it is not managed by the zend memory manager. Of course... Also, running valgrind and taking a closer look at what memory blocks PHP is allocating here it can be better determined what's leaking and what isn't, of course... http://pastebin.com/LSQcUsBL I can certainly attest to users being deceived by memory readings in top in the past. It can be very deceiving if you think look at what free memory top or `free` shows you especially after some huge allocation. There's a clear difference here though between the Zend memory manager allocating these blocks in PHP and what's going on with readfile. The memory the system knows is available to it isn't being tied up in this case. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] readfile() memory usage
On 04/30/2012 07:37 PM, Paul Reinheimer wrote: Hi Larry, 4) So given #2 and #3, the readfile() will kill your memory, don't use it line is a persistent urban legend that belongs on Snopes as debunked. Looping on fread() for performance is a red herring. I implemented this earlier this very year to avoid memory issues (a quick look at project history shows me working on it in January). The difference between using readfile, and some convoluted method from the documentation comments was clear and immediate: corrupted download with out of memory error in the logs, to things working just fine. Let me re-create with a simple test script and share my server details before we call snopes :) Fascinating. I even verified the md5sum of the file I got on the other end just to be sure. I'll hold off on the blog post then. :-) I look forward to your test setup. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] readfile() memory usage
On 5/1/12 10:01 AM, Paul Reinheimer wrote: Hi All, Unfortunately, you've ignored Uwe's e-mail... The problem is not the PHP version; the problem is that you're buffering unlimited amounts of data. Check your configuration and make sure ob_get_level() returns 0. My apologies in the delay, ob_get_level() returns 1, good catch. phpinfo() reports output_buffering as 4096 Does this push what I'm getting into expected behaviour? paul It sounds like it. In that case the memory spike is happening in the output buffer, where the file is streamed into by readfile() in 8K chunks until the output buffer explodes. :-) So, I think we're back to urban legend territory. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] readfile() memory usage
On 05/01/2012 11:40 AM, Larry Garfield wrote: On 5/1/12 10:01 AM, Paul Reinheimer wrote: Hi All, Unfortunately, you've ignored Uwe's e-mail... The problem is not the PHP version; the problem is that you're buffering unlimited amounts of data. Check your configuration and make sure ob_get_level() returns 0. My apologies in the delay, ob_get_level() returns 1, good catch. phpinfo() reports output_buffering as 4096 Does this push what I'm getting into expected behaviour? paul It sounds like it. In that case the memory spike is happening in the output buffer, where the file is streamed into by readfile() in 8K chunks until the output buffer explodes. :-) So, I think we're back to urban legend territory. --Larry Garfield Thanks for the sanity check, everyone. I've put together a blog post with my findings. If anyone wants to check it to make sure I am not saying anything grotesquely wrong before I posted it, that would be much appreciated. :-) It's set to world-commentable: https://docs.google.com/document/d/1qfe4OUc5lbuoSZFUh6NZYP-6pbaiquxnOFwN_oBccBI/edit --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] RFC - array_column() function
On 06/22/2012 04:20 PM, Scott MacVicar wrote: Hey Ben, On 22 Jun 2012, at 08:52, Ben Ramsey wrote: On 6/22/12 5:32 AM, Léo Peltier wrote: Hi, Shouldn't this be called 'array_pluck'? This is the name people usually use when implementing it in PHP (see array_pluck( vs array_column( in Google) or in other languages/libs (see underscorejs, prototypejs and RoR). I'm open to changing or aliasing the name to array_pluck(), if others are in agreement. We have a version of this at Facebook and its called array_pull() it has a third parameter and supports pulling a new key value too. You can find a copy of it in Phabricator. There is also mpull() which is for methods. I'd recommend combining the two methods to be honest and doing a single function that supports index names or a method. https://github.com/facebook/libphutil/blob/master/src/utils/utils.php#L143 - S +1 on this functionality from me. I've had to implement it in user-space way too often. :-) For the name, I'd suggest doing a survey of other languages that PHP folks are likely to have had experience in and going with whatever seems most common/similar to what's proposed here, rather than debating it directly. :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On closures and lamdba
On Tuesday 23 February 2010 05:00:28 pm Ionut G. Stan wrote:
This is not entirely correct, you are right. There's a difference
between anonymous function and closure, though in practice in PHP
anonymous functions are closures (though some of them are rather trivial
ones with no variables to close over) and that's now the only way to
do closure in PHP (i.e. you can't have non-anonymous closure function).
Correct me if I'm wrong, but given the fact that PHP only* supports
functions defined in the global space**, with the additional ability to
import global variables using the global statement, wouldn't that make
named functions able to close-over global variables?
And, if the above is true, wouldn't it be consistent to support the use
statement on named functions, and then deprecate the global statement?
I remember one of the first implementation for closure, used a statement
similar to global for closing over variables (the lexical statement).
IMO, globals could and should use a similar syntax to lexical closures:
function foo($a, $b) global ($c, $d) {
// ...
}
That would allow a parallel syntax, and allow for both by-value and by-
reference globals, which currently we cannot do. And closures/lambdas
could/should support the same syntax for globals.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: moving forward
On Monday 15 March 2010 12:56:07 am Herman Radtke wrote: There are a number of ways to share your branches with others. At least you can do it by pushing your local changesets to some remote repository. I've actually been experimenting with modified PHP core with some language features added by forking the mirror on github.com [1]. I've never felt any inconvenience there. I really appreciate those who set up the mirror. Yes, this is possible, but in my experience branch sharing quickly falls apart in practice. If I make some change to foo.c, push it to your branch and then later on do a rebase to update from svn I just rewrote history. The commit hash you have for foo.c is now different than mine. Now sure you can also rebase, but what if you are away? I am stuck until you return. Or what if you have a commit to foo.c that is made after my commit, but updating from svn creates a conflict you need to resolve? You then again rewrite history and now I have to sync back up. And good luck if one of us cherry-picks. I think git svn does a great job for individuals working solo on a project, but for me it starts to become too tedious when groups of people are passing around branches. Or maybe I am just doing it all wrong? If I may pop in here a moment, my company has done a few projects recently using git, and Drupal (the main project I work on) is in the process of planning a git migration. I make no claims of being a git expert (I've only used it on one project so far personally), but my understanding from those who are is OMG WTF are you doing rebasing??? 99% of the time that's not what you want to do. You just want to do a straight up merge from the parent branch to your branch off of the parent periodically. That may resolve the issue you're describing. --Larry Garfield, not a git expert by any means, just repeating what he's been told by people who know more than him -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [fw-webservices] Re: [PHP-DEV] RFC - class underloading -or- ancestor overloading
The challenge of never use extend is that simply wrapping classes in
decorators only goes so far. You can't always maintain interface compliance
if you're nesting decorators, and if you're overriding only one out of a dozen
or two methods then you have a lot of foo() { return $obj-foo(); } method
implementations. Aside from being hard to read, that also eats up cycles for
the extra stack calls. __call() can make it much less code but is also much
slower.
If there were a syntactic-level support for wrap this object in this class
and pass through any method that isn't redefined, a sort of sideways extends,
that would become much simpler. I'm not sure what that would look like,
though.
Or perhaps this is a good time to revisit the traits proposal from a few
months back?
--Larry Garfield
On Monday 15 March 2010 12:36:32 pm Hector Virgen wrote:
I also ran into this problem with Zend_Db_Select. I wanted to add a new
constant to improve my usage of Zend_Db_Table#select(), but that method
would always returns an instance of Zend_Db_Table_Select which extended
Zend_Db_Select. There was no easy way for me to add my class constant
without resorting to one of the 3 methods Chris mentioned.
Another possible solution (although it would require a rewrite of the
framework classes) is to avoid using extends entirely. This can be
accomplished by using interfaces instead, which is explained in this
article:
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
Although the article is a bit dated and it's for Java, the concept still
applies and can help developers make better use of framework code by
inheriting only the implementations they need while providing alternate
implementations when necessary.
Maybe this can be a design paradigm to attempt to follow in ZF 2.0?
--
Hector
On Sat, Mar 13, 2010 at 8:10 AM, Richard Quadling
rquadl...@googlemail.comwrote:
On 13 March 2010 01:50, Chris Trahey christra...@gmail.com wrote:
Perhaps a new concept in class-based OO programming, I'm not sure.
Depending on your perspective you could call it ancestor overloading
(or upstream overloading) or class underloading.
We are increasingly developing with the aid of frameworks libraries.
In fact, this idea came from my current project using the Zend
Framework.
These libraries, while greatly extensible, are also fairly
self-extending.
That is, they include many classes that extend many classes, which is
great.
As consumers of these libraries, we can extend the classes and consume
the
API however we please, but there is one sticking point.
We cannot change classes that many other classes extend without
extending
or
changing each child class and then making sure that our code uses the
new class.
For a concrete example, I was working with the Zend_Form_Element
subclasses,
and I realized that I wanted to change some of the default behavior (in
Zend_Form_Element).
- at this point I will assume the reader understands why I wouldn't
want
to
just start changing the Zend library files -
There are many subclasses of Zend_Form_Element. If you want to change
the default behavior for all of them, you have 3 choices currently:
1. Directly edit the Zend_Form_Element file in the library, -bad for
updates
other projects that use the library
2. subclass Zend_Form_Element and change declaration of the descendants
to
extend new class - same problems
3. extend each child class and implement those subclasses in your app
code
-very tedious and TONS of repeated code, breaks consistency of API for
developers.
There could be a better way, if we could insert a class into the family
tree.
And that's the heart of this idea, so I'll repeat it:
* insert a class into the family tree *
Image we do it using an alternative keyword to extends, such as
overloads.
Example:
class Library_Class { }
class Library_Subclass extends Library_Class {}
and then:
class My_LibClass_Overload overloads Library_Class{}
Now new instances of Library_Subclass actually extend
My_LibClass_Overload,
which extends Library_Class. The developer would then code
My_LibClass_Overload as if it were declared like this:
class Library_Class {}
class My_LibClass_Overload extends Library_Class {}
class Library_Subclass extends My_LibClass_Overload {}
But indeed the declaration of Library_Subclass would *not* have to
change.
This way developers could extend default functionality and have
*existing*
library classes pick up the new functionality without redeclaring
anything
in the library.
Downstream classes would still override any methods that they
redeclare.
If
you wanted to have end-point classes
Re: [PHP-DEV] Re: [fw-webservices] Re: [PHP-DEV] RFC - class underloading -or- ancestor overloading
On Monday 15 March 2010 03:08:28 pm Nate Gordon wrote: If there were a syntactic-level support for wrap this object in this class and pass through any method that isn't redefined, a sort of sideways extends, that would become much simpler. I'm not sure what that would look like, though. Or perhaps this is a good time to revisit the traits proposal from a few months back? While traits do seem pretty cool, the fundamental problem appears to be that Framework X doesn't let me do what I want. Unfortunately that is the side effect of using a framework, it does things for you. I had attempted to build a system like this in userland code to dynamically replace classes in my framework, but scrapped it because I could only see ways in which it would be abused. If someone replaces a class buried in a framework, that modifies some bit of functionality, which is depended on by a completely unrelated area of the framework, it could potentially cause issues that would be very hard to track down. This sounds a lot like aspect oriented programming in the ability to completely overwrite a function with userland code. I feel like the better solution is to fix the framework to allow the flexibility to do what you want in a controlled manner, and not bend the language to fix the framework. I don't mean to say that PHP is problem free or perfect, but I'm not sure this is the best method to fix the problem at hand. Certainly true; it's not PHP's job to work around framework flaws. However, if PHP can make it easier to make frameworks that don't have common flaws, that is something it can and IMO should do. Traits wouldn't fix the issue mentioned here, but might allow the framework to be written in a way that doesn't have, or at least ameliorates, these sorts of issues. Or perhaps there's a different approach besides traits that would work better. I dunno. :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Thursday 18 March 2010 10:05:39 pm Eric Stewart wrote: +1 For shorter release cycles. Shorter release cycles could also allow us to move major releases immediately to bug and security fixes only. I've never been a fan of seeing additional features added in minor releases. It's confusing enough to try and keep track of features from one major release to the next, but then we add in features on minors as well. That feature was added in 5.3.1. Obviously this was not a good option when major releases were at 12 months or more apart. If we can shorten the cycle, I think it might be a good idea to visit how quickly each release is frozen to bug and security fixes only. This may just be a developmental pet-peave of mine, I'm sure I'll hear about it soon if the idea is unfavorable. As an additional note to this, performance patches which don't add additional features but only increase speed would still be fair game. P.S. 2: Reduced release cycle times might reduce the burdens on RMs as well by allowing them to commit to shorter time periods of release management responsibility. Not that I hear any of them complaining, just thinking this might be another good reason to give it a try. Eric Lee Stewart If I could step in for a moment, while there's certainly advantages to shorter release cycles that others have mentioned there's another factor that has to be considered: Backward compatibility would have to be much more tightly monitored. Out in the shared hosting world, we're at the mercy of web hosts and Linux distributions. They don't like to upgrade stuff if they don't have to, and often times not even then. It wasn't that long ago that we needed an industry-wide boycott, essentially, to force PHP 5 at all. Most hosts aren't on 5.3 yet. That means any mass-market PHP projects (Wordpress, Drupal, Joomla, CakePHP, Symfony, CodeIgnighter, etc.) are still working with 5.2 at best, and it may be some time before the I don't have root on my server and don't know how to compile stuff myself crowd (read: the vast majority of the market) is able to leverage 5.3. When significant releases are 2-3 years apart, web hosts can expect to have to put in actual work every couple of years and mass-market developers can expect to have to beat their hosts over the head with a stick every few years. If significant releases are going to be every year, then it has to still be easy and safe for hosts to upgrade. Preferably it has to also make servers faster because then they have an incentive to upgrade themselves. If hosts don't upgrade, it doesn't matter what amazing new features PHP has. Most people can't use 'em. I'm not against a more planned, frequent release cycle but I want to make sure that the upgrade treadmill is kept walkable or else it won't matter that PHP has new features. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Removal of deprecated features
On Friday 16 April 2010 05:23:42 am Ferenc Kovacs wrote: I think that the hosting providers will do notice, and either not migrate, or send a mail to their users, warning to check their settings because if they are depending on the magic quotes, they will be in danger. So I think we don't have to wait for the shared hosting providers, because they will catch up as slow or fast as we go. Given how long it took them to catch up to PHP 5 in the first place I don't think we can count on that. Such breakage should come in large chunks so that hosts only have to wring their hands once every so often. Otherwise they just won't upgrade ever. Most run on very thin margins. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Saturday 22 May 2010 11:43:50 pm Zeev Suraski wrote:
At 01:01 23/05/2010, Hannes Magnusson wrote:
On Sat, May 22, 2010 at 22:39, Lukas Kahwe Smith m...@pooteeweet.org
wrote:
On 22.05.2010, at 18:30, Josh Davis wrote:
As you wrote, you worked on PHP's _type system_ which is dynamic,
really cool, juggles strings with ints and what not. However, the
topic here is the _type hinting system_. As far as I know, there's no
weak type hinting; if a method signature hints for an array and is
given an integer, it throws a catchable fatal error. Therefore, as a
user, what I am familiar to is a strict _type hinting system_.
Anything else would feel inconsistent to me.
I agree. function foo(array $x) {} foo(123); doesn't cast int(123) to
array(123) so introducing different meaning for scalar types feels
very very wrong.
You're ignoring one simple fact - in PHP, scalar types are
interchangeable. Unlike array-scalar which has always been a corner
case and a sketchy one (and I said numerous times that had I rewrote
the language now, array-scalar conversion would have probably
resulted in an error) - string-number, number-string,
string-boolean conversions are a cornerstone of the language. If
you don't like the fact that PHP's scalar types are interchangeable -
you're in the wrong language!
In terms of consistency, the difference between array type hinting
and scalar type hinting you allude to is negligible in comparison to
the inconsistency with, well, just about every other part of the
language - operators, control structures and built-in functions
(expecting sqrt(64) to fail, since sqrt() expects a
number? expecting if (7) to fail, since it expects a
boolean?). Auto-converting type hinting extends the same semantics
available to internal functions (through zend_parse_parameters()) to
userland functions. That consistency is by far the most important IMHO.
Zeev
I have to largely agree with Zeev here. I'm not an internals developer but I
do write a lot of widely used framework-ish open source PHP.
The current OO type specifying system I have always mentally viewed, and most
people I know seem to view it, as a check not for is this an X, but can I
treat this as X without things exploding? In the context of an object,
exploding would mean a method not found fatal. In the context of an
array, it would be the dreaded parameter 1 to foreach() is not an array.
The idea is two fold: One, better documentation (especially for code
assistance IDEs), and two, if it's going to explode it should explode in a way
that's useful in terms of where it exploded. (Vis, the error message is on a
useful line and tells me what the actual problem was.)
For scalar types, exploding would mean loss of precision. There is no loss
of precision in converting 5 to int(5), so that doesn't explode, nor should
it. There is similarly no loss of precision converting from int(5) to
float(5), so that also shouldn't explode. 123abc does have a loss of
precision (data would get lost in the conversion) so that should fail both int
and float checks.
If anything, I'd be even more forgiving than the table in Zeev and Lukas' RFP.
float(12) converting to an int doesn't have any precision loss so I don't think
that should fail.
The RFP includes a variety of good reasons why a more naive strict check is
inconsistent to the point of making it a bug rather than a feature. One in
particular I want to call out: Everything that comes back from a database does
so as a string. To wit:
table users(user_id, name, pass, blah);
$user_id = $pdo-query(SELECT user_id FROM users WHERE name='bob' AND
pass='foo')-fetchColumn();
doStuff($user_id);
function doStuff(int $user_id) {
// Whatever.
}
The above code will fail with the current implementation, even though we know
for a fact that user_id is integer data because that column is an int in the
database itself. Requiring an extra blind (int) stuffed in there is pointless,
and if anything just trains people to blindly cast data without thinking about
what it really is. I can see that introducing more bugs than it avoids.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Monday 24 May 2010 12:09:30 am Zeev Suraski wrote: I have to say that I don't really see the logic in either it should be identical to PHP's conversion rules or it should be 100.000% different (strict). Adding strict typing would be the largest inconsistency in PHP's core syntax, ever. For that reason, I prefer pretty much any variation of the proposed solution over strict type checking. I see three key options going forward: 1. Implement the table along the lines of what it looks like now, perhaps with minor changes. 2. Implement identical conversion rules to the ones that exist in PHP; That effectively turns type hinting into scalar casting operators (not saying that's a bad thing!) 3. Implement identical conversion rules to the ones that exist in PHP, except for when they really suck. Namely, lose the array-scalar conversions and silent conversions of non-numeric strings to numbers. I personally lean towards #3. Zeev #3 is the one that seems like it would be most useful in practice, with one caveat. If given an input of float(5.4) and a function parameter specified as int, there is data loss if you just do the equivalent of (int)$foo so that falls into the really suck category and should also explode. (float(5), however, has no data loss in that operation so it's safe.) I don't know if there's performance issues to address with that addition that may nix it, but that would be the ideal. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Friday 28 May 2010 01:54:55 am Zeev Suraski wrote:
At 08:28 28/05/2010, Tjerk Anne Meesters wrote:
On the other hand, auto-casting used to be my favourite until I
glanced over the conversion table; it's not just regular casting, it
has different rules. I wouldn't want to be the one going over that
table when writing code against a certain API, I should only need to
see the documentation.
Tjerk,
I think you have a nice idea about E_STRICT, except it makes much
more sense with auto-conversion. That is - in case of 'fail' - we'd
still convert, and emit E_STRICT (or E_NOTICE). That means that the
API developer will always get the type he expects, while the user
will be guided in the right direction in a friendly PHPish manner.
The conversion table is up for discussion, BTW. If most people
prefer that it's more similar to PHP's existing auto-conversion rules
(that appears to be the case) we can certainly do that.
Zeev
I'm not 100% sure I follow, Zeev. Are you suggesting:
foo (int $a) { }
foo(1); // Works, no message
foo(1); // Works, no message
foo(1a); // Emits E_STRICT or E_NOTICE and casts to a 1
foo(array(1)); // Fatal
I could get behind that. In fact it also suggests that we could (later?)
alter the normal casting rules so that if you do a lossy conversion you get a
notice/strict in any case. Something to chew on.
I like that idea, as the purely strict typing that's in HEAD right now I find
worse than having no scalar type checking at all.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dangerous handling of security bugs
On Wednesday 14 July 2010 03:22:30 pm Dirk Haun wrote: Am 13.07.2010 um 17:12 Uhr schrieb Ferenc Kovacs: it would be an interesting to check how many bugs were first marked as bogus then re-opened and fixed. I've been wondering for a while now if much of the emotional reaction to bugs being closed as bogus is due to that very word. I mean, the reporter obviously put some work into the bug report and the issue was apparently important enough for them to even bother opening a bug report in the first place. And then, after all this effort, the verdict is that it's bogus. Can't really think of a good alternative right now. But if a bug was closed with a more neutral can't reproduce, works as designed or something like that then maybe there wouldn't be such strong reactions? Just an observation from the side lines ... I'd have to agree. Bugus has an implication of fake. As in, the submitter faked a bug report. That is rarely the intent, I'm sure. For the Drupal project (which I work on), our no issue statuses are by design, postponed, and won't fix. (And of course duplicate.) I sometimes wonder if won't fix is even too negative sounding. It's amazing what a little wording can mean, especially to new contributors. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Please reconsider supporting PHP 5.2
On Sunday 25 July 2010 05:55:53 am Reindl Harald wrote: A clean designed application has to run the whole time with error_reporting = E_ALL | E_STRICT and so you should have seen the problems long ago This broke Drupal 6 big time and while core has been fixed, contrib is a bit slower to adapt. Previously, it was possible to pass in simply NULL if you did not care about the by-reference argument. The problem is that the developers of drupal, joomla, wordpress are not working error_reporting = E_ALL | E_STRICT as i do since teh first day i use php even on production servers One catch here is that E_STRICT implies no PHP 4 compatibility, as E_STRICT chokes on PHP 4-style class usage, etc. Drupal 6 had PHP 4 compatibility so E_STRICT was not an option. The core system was developed to E_ALL standards, but not all add-on modules (which are the lifeblood of any modular framework) are. I cannot speak for other projects but since Joomla, Wordpress, and CakePHP all were PHP 4-friendly until their most recent versions at least I suspect the story is much the same. I'm not disagreeing with you about writing pedantically correct code from the get-go (I've been a strong advocate of that in Drupal for quite some time), but when you have a code base that goes back nearly a decade and need to not lock out casual module developers who don't understand the intricacies of error level configuration and don't have root on their servers it's (unfortunately) not as simple a question as you make it out to be. That said, I'm actually against the removal of $foo(), not for BC reasons but because call_user_func() is *not* a viable replacement (it's actually considerably slower), $foo() is much easier to read (IMO), and because I've never once been confused by ::$ that I can recall. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Supporting Binary Notation for Integers
On Wednesday, November 10, 2010 5:46:50 pm Matthew Fonda wrote: On Wed, Nov 10, 2010 at 2:51 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Wed, 10 Nov 2010 21:31:19 -, Jonah H. Harris jonah.har...@gmail.com wrote: Hey all, I was recently working on some code which made use of bit arrays and I came across feature request 50648: Format for binary numbers. While it's just more syntactic sugar (0b1011010 vs 2010/0x7da/03732), it doesn't seem like too bad of an idea and it is also supported by a few other languages. If there's any interest, I'll clean up the patch and resubmit. I think it's a good idea. It won't spark interest in those that have already memorized the more compact hexadecimal representation of nibbles, but otherwise it's useful a simple non-BC breaking addition. Agreed. I have often thought this would be useful. Best regards, --Matthew Especially given how common it is to use hex constants as bit flags, being able to define them in binary to begin with would help readability. (Yes, I just said writing in binary would help readability. God help us all. g) +1 --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion
On Wednesday, November 17, 2010 5:56:05 am Ferenc Kovacs wrote: On Wed, Nov 17, 2010 at 12:54 PM, Ferenc Kovacs i...@tyrael.hu wrote: On Wed, Nov 17, 2010 at 11:58 AM, Arvids Godjuks arvids.godj...@gmail.com wrote: Hello Internals! For me, as a user-land developer, this issue seems as if some people are trying to push the annotations at any cost. What they fail to see, is that annotations are never described what they are and how they can be useful in our developer work. Right now I, and I think many other user-land developers, just fail to see what the annotations are without any meaningful example. *snip* On the other hand: it seems that more examples about the usage wouldn't hurt in the RFC... Tyrael I have to agree with this sentiment in particular. As I've not worked in a language with formal annotations, I still don't grok the use case. To those supporting some form of syntactic annotations (whatever the syntax), can you please explain, simply and preferably with examples, what I could do with such syntax that I cannot do now in user-space, and/or what I could do better/faster/cheaper with such tools than what I can do now in user-space? I think that's the missing piece here: The practical ever-day example of how *my* code would get better because of annotations. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes in trunk
On Wednesday, November 17, 2010 11:19:05 pm Philip Olson wrote: What are your inputs on this matter? I'm struggling with this topic. We must do something, but it's important to understand that plenty of people unknowingly rely upon this security feature that's still enabled by default. Granted 5.3 does generate E_DEPRECATED errors when magical quotes are enabled, but is one minor PHP version of errors enough to go from on to gone? So while those in the know (e.g., people who follow this list) find them annoying and wish they never existed, what are the implications? I'm still unsure how best to handle this situation but wanted to express these feelings now. Whatever the case, the education effort towards data filtering and sanitization requires a lot of improvement. Regards, Philip I won't miss magic quotes if they're removed, but I can see the argument for saying not quite yet. Off-by-default is absolutely necessary if they're kept. (Dear god, you mean they aren't off by default already?) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Wednesday, November 24, 2010 8:12:25 pm Daniel Brown wrote: On Wed, Nov 24, 2010 at 20:47, Pierre Joye pierre@gmail.com wrote: hi, [snip] Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. You might recall several conversations on this during the period where Gwynne was migrating us from CVS to SVN in 2008/09. Two two threads that stand out most in my mind were Rasmus' thoughts on the matter[1] and David Soria Parra actually working toward using git --- or at least git-svn[2]. There were several other threads on the subject as well, so unless opinions have changed, you may already have some folks in your corner. ^1: http://news.php.net/svn.migration/255 ^2: http://news.php.net/php.internals/44942 FWIW, the KDE project migrated from CVS to SVN a few years ago and is now in the process of migrating to Git following numerous KDE projects moving to Github of their own accord. They're doing a piece-meal approach with projects migrating bit by bit. I believe they are hosting their own Git setup but I'm not certain of that. The Drupal project skipped SVN entirely and is currently in the process of migrating our entire infrastructure from CVS to Git, which we will be self- hosting. Numerous Drupal projects were already migrating to Github and we decided, basically, CVS sucks and people are voting with their feet for Git. We opted to setup our own Git infrastructure rather than use GitHub's because our development toolchain is very tightly coupled with our version control system and issue queue history, and we wanted to retain that. We couldn't do that on Github, but building our own we could. A nice side-effect of this process (in progress as we speak) is a number of more generic tools (many Drupal-based, I grant) for version control handling, particularly Git. By the time we're done (hopefully late Q1 2011) we should have a number of people who know a disturbing amount about Git and Git-PHP, and I suspect many could be coaxed to at least provide advise and consultation if not actual labor. (I am not one of those people so I can't speak for them, but I would certainly be willing to poke and prod people into offering what help they can. g) Having been an SVN fan for a long time, I must say I am *really* liking working with Git for the past year or so on various projects. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Sunday, November 28, 2010 9:12:34 am Felipe Pena wrote: 2010/11/28 Ross Masters r...@php.net From what I understand T_FUNCTION would be optional, rather than removed altogether, is this the case? This would allow those who want to use it the option of using it and would not break existing code. Yes, exaclty... File me -1. The above argument is oft-used but is not, in fact, a valid argument unless all of the code you work with is your own. The minute you start using 3rd party code (you know, sharing generic libraries in good software engineering and open source etiquette) you are at the whim of whatever syntactic options they chose to use. Optional function, strict typing, exceptions, the list goes on. There is no such thing as an optional language feature if you're working with code you didn't write. Given that, making functional optional makes the language more complex (for me visually scanning it, for an IDE parsing it, etc.) in order to save a few characters. Bad trade-off. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Sunday, November 28, 2010 11:24:02 am Dallas Gutauckis wrote:
I understand the concern from above, but I don't agree with it
fundamentally. The kind of practice suggested by this search mechanic tells
me that either there is lack of or little documentation, and lack of or
little understanding of the codebase in which the code resides thereby
making this argument flawed based solely on the assumption that the
majority of code is (or should be) poorly maintained/documented.
Below is simply bad programming practice in many ways. No validation of
type (neither through type-hinting nor an instanceof check) is done, which
is why the code is so difficult to trace back. Presumably, you'd also have
some form of documentation (PHPDoc, anyone?) that would facilitate the
search for the declaration of that function. Again, that assumes a better
programming practice than is being provided as the example below. One
would hope that someone excluding their function keyword would also be up
to date enough to be validating objects.
function baz( $param ) {
$param-morlocks();
}
I would like to know how to get to the fantasy world you describe in which all
developers are doing careful type checking and proper DocBlocks on everything.
It sounds like it would be a glorious place to live, if only it could exist.
(I routinely beat people over the head about that in a project with very good
documentation standards, and we still have extremely good developers writing
code that fails both of the above.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On Sunday, November 28, 2010 5:18:40 pm presid...@basnetworks.net wrote:
Link to the RFC:
http://wiki.php.net/rfc/propertygetsetsyntax
Thanks,
Dennis Robinson
This is a very well-written and well-thought through RFC, Dennis. Nicely
done.
That said, I am not yet convinced. :-)
First of all, I have generally found the Bean-style getter/setter approach to
be a sign of poor encapsulation to begin with. You shouldn't be mucking with
internal elements of an object in the first place, period. More details on
that here:
http://www.garfieldtech.com/blog/property-visibility
However, I do see a potential use here if properties are treated
conceptually as an entirely new concept and not as an indirection layer for
class properties. That would make them more akin to a class that has both
methods and also implements ArrayAccess for properties of the conceptual
object, that may not have anything to do with internal class members.
Viewed from that angle, I would have the following comments:
- I strongly prefer the first syntax over the second. The property keyword
improves readability, and the closing semi-colon is going to be forgotten on a
daily basis. I still forget sometimes when to use it and when not to when
writing Javascript. :-) I cannot speak to the engine complexity involved but
from a PHP-autor point of view I believe the first syntax is much easier to
use.
- The use of identical syntax for class members and properties could create
confusion as to which is which. One could argue that is the point, but only
if we view properties as just an indirection layer around the physical class
members, which as I noted above I believe is a poor architectural design.
There may not be an alternative here, but I mention it for completeness.
- I concur with the RFP's preference for implicit write-only properties
rather than explicit, as it seems more flexible.
- The layering of accessibility keywords I find intriguing, in a mostly good
way. That can offer a great deal of flexibility to control who can do what
when. However, I am concerned about the confusion possible in the following:
public property Hours {
get { return $this-seconds / 3600; }
protected set { $this-seconds = $value * 3600; }
}
The set method is then scoped with two different visibility directives: public
and protected. Which applies? Since both are optional (presumably) I can see
a potential here for confusion, especially if you also start mentioning
keywords like final. This should be made more definitive if possible.
- If interfaces can declare properties (niiice), Traits should be able to
provide them. That provides full parallelism with methods, which I believe
developers will expect.
- I am curious what the performance implication would be. For instance, I've
benchmarked both magic property access (__get()) and ArrayAccess to be around
4 times as slow as accessing a class member.
http://www.garfieldtech.com/blog/benchmarking-magic
Since in essence what is happening here is binding a function to fire when a
class member is accessed (given the identical syntax), I'm concerned that
there would be a similar performance issue. A 4x slower performance cost
would make me avoid properties in favor of class members unless I absolutely
needed them. A 2x or less I could see making more use of.
- Which also brings up an interesting question:
class Foo {
public $a = 1;
protected $b = 2;
public property $a { get { return 3; } }
public property $b { get { return 4; } }
}
$f = new Foo();
print $f-a . PHP_EOL; // Does this print 1 or 3?
print $f-b . PHP_EOL; // Does this print 2 or 4, or error?
I'm sure there's arguments every which way. My preference would be for
properties to always win over class members, followed by the above code sample
being a compile error.
It gets even tricker when you introduce inheritance. If a child class has a
[property|class member] of the same name as a parent's [class member|
property], then what?
That's all I got for now. Once again, nice RFP but still needs some thinking.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
The Drupal project's decision making process for moving to Git is documented extensively here: http://groups.drupal.org/node/48818 Just another data point. --Larry Garfield On Wednesday, December 01, 2010 2:52:53 pm dukeofgaming wrote: Hi, I was following this path to push the adoption of a DVCS for the Joomla project and I started to create the required documentation to make an informed argument and evaluation, I made some diagrams to make the case for their need for good team development and workflows, feel free to borrow any content/diagrams from here http://docs.joomla.org/Dvcs If an RFC is started I'd love to help. I have experience with git and mercurial. http://docs.joomla.org/DvcsRegards, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On Wednesday, December 01, 2010 8:28:19 am presid...@basnetworks.net wrote: Is this consistent with methods? Do those share a namespace, too? (I don't actually recall off the top of my head.) methods and variables have their own namespaces. This is because they are called differently: // variable $a print $f-a; // method a() print $f-a(); But variables and properties would be called the same way (both $f-a;). Because of this, they need to share the same namespace in order to avoid ambiguity. This is in fact a feature of properties, because this way an existing variable can later be replaced with a property, and all calling code will continue to work (or at least will compile). See, here's the fundamental problem we're running into. There's three different definitions of what a property is that we keep bouncing between, each of which will dictate both syntax and semantics: 1) Properties are a smart masking layer over class members, like a smarter __get/__set, designed to make it possible to swap out in place of class members at will. In this case, both the syntax and semantics of properties should mirror class members as close as possible. 2) Properties are a short-hand for getFoo()/setFoo() methods (which in the general sense should *not* be understood to always map to class members, as discussed), designed to make typing $o-getFoo() and $o-setFoo() shorter/easier. In this case the syntax and semantics should make that clear and not confuse the user with class-member-like syntax. 3) Properties are a completely different animal, neither methods nor class members but a totally different concept. In this case the syntax should not be confusing with either methods or class members, and the semantics should probably then be taken from the most common/popular existing implementation feasible. We cannot mix #1 and #2 and expect to get something usable out the other end, nor can we defend doing so on the grounds of #3. The discussion of the proposal is doing exactly that, however, which I think is a fatal flaw. Personally, if we follow approach #1 (make them look and smell as much like class members as possible) then I'm all for it in concept. It might even simplify many of the regular arguments I have about public properties and good architecture. :-) But only if we can cleanly stick to one definition of purpose, syntax, and semantics. Treating properties as a method implementation that can work like class members if you look at them from the right angle even though they're not class members and don't really work like them is a sure-fire way to confuse the hell out of people. PHP is complicated enough without introducing wave/particle duality. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Marking DateTime Instances Immutable
I'd love to have a Value Object version of DateTime, as its current behavior is quite annoying. However, making it a toggle on the existing class does not make sense to me. A function or method that gets called with a DateTime object then doesn't know if it is safe to modify or not, and if the return value from a method will be a new object or not. That means I need to also pass around a flag saying which it is, or else have a method to ask DateTime which mode it's in and then fork my own code to account for both cases. That's ugly. :-) I think it would be better to have a new DateTimeValue class that subclasses off DateTime (or even better, introduce a new interface that they both implement) that is essentially identical but is immutable. That would make it much easier to code against. --Larry Garfield On Saturday, December 04, 2010 6:11:37 pm Benjamin Eberlei wrote: In the current implementation DateTime is not a value object, but its internal state can be modified at any given time. This can lead to very obscure bugs when references to DateTime objects are shared or objects are passed through a chain of methods/functions that modify it. Using DateTime is not side-effect free. I propose to allow to work with DateTime objects that are marked as immutable optionally. This means that all methods add, sub, modify, setDate, setTime, setISODate, setTimestamp and setTimezone will return a NEW instance of Datetime instead of reusing the old one. I also talked to Derick about this and he agrees that immutable DateTime objects would be desirable. I have talked to many other people who agreed that the current behavior is weird. My proposed syntax would be: $immutableDateTime = date_create(2010-12-05, null, true); $immutableDateTime = new DateTime(2010-12-05, null, true); $immutableDateTime = DateTime::createFromFormat(%Y-%m-%d, 2010-12-05, null, true); Where the third and fourth variable respectivly are boolean flags $immutable yes or no. Also the DatePeriod iterator would be modified. If an immutable start date is passed the date iterator would also create immutable dates. I have attached a patch that implements this functionality and a little test-script that shows how it would work. This is the first complex bit of C-code that I did so please bear with any mistakes I made ;-) Also i havent followed the coding standards. Any feedback is greatly appreciated. My C-Skills arent that good so i am not finished with an additional solution allowing to call a method setImmutable() on any datetime instance, marking it as immutable. Obviously this would only mark the instance as immutable, allowing to accept a flag to reset it to be mutable would be counter-productive. The only drawback I see to this patch is the additional int variable on the _php_date_obj and _php_date_period structs. I am not sure if they affect memory in such a way that this solution isn't viable. If this topic needs more discussion or pro/cons I am willing to open up an RFC for a more detailed discussion. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On Sunday, December 05, 2010 11:07:49 am presid...@basnetworks.net wrote: The original purpose being, specifically, smarter class members, correct? (The internal syntax to define them we can bikeshed later; determining the external syntax and semantics has to come first.) Well when saying original purpose I was referring to exactly this: The basic Idea of a property, is making a getFoo() / setFoo($value) pair of methods look and act like a variable from the outside, and have an easily identifiable and simple to use syntax on the inside. But I suppose you could just boil that down to smarter class members ;) - Dennis Well, there's a very subtle difference in those two statements. :-) That's what I'm saying. If the goal of properties is to allow a developer to bind arbitrarily complex behavior to what would otherwise look like a class member, that's fine and useful and I support it. But there are, technically, multiple very different ways that could be implemented. An inline set of get/set methods is one way. Creating a property as a reuable free-standing entity alongside traits and classes would also accomplish that goal. Creating a free-standing super-variable dojobby would work, too. Technically __get/__set also accomplish that goal now (although in a sub-optimal way). I'm trying to draw a very clear line between the syntactic interface and goal, and the implementation. That's important for us to keep the design clean. And I think I'm done harping on this point now, I hope... :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC __autodefine / spl_autodefine
On Monday, December 06, 2010 6:59:08 pm Ross Masters wrote: Hi Sebastien, __autoload() should die (as in get deprecated ASAP and later removed) I couldn't find anything about your opinions on this so I was wondering if you could elaborate. Do you consider autoloading as a bad practice or just that spl_autoload_register should be used to add relevant functions/closures? __autoload() works fine if you have exactly one implementation for your entire system with exactly one set of logic for how to map a class name to a file name. As soon as you try to mix two different libraries together, fatal error. spl_autoload() does not suffer from this short-sighted problem but accomplishes the same goal in a much more robust fashion. Any new meta-auto-load mechanism should forego the dead-end that is a single unique __auto*() function and just use a design that actually works, aka spl_autoload() or similar. With that said, I like the idea of generalizing autoload to include functions et al. Autoloading functions would make my life a lot easier. :-) To be fair, though, half of the potential benefits the OP listed are already solved by using a version control system. Any version control system. If you're still having collisions at the file level when two people work on the same file it's because you're an idiot and are not using version control (or the changes touch each other, in which case this proposal wouldn't help you anyway). The main advantage of this proposal would be lazy-loading of functions. I don't think autoloading methods makes any sense since classes cannot be split between files anyway. I'm not entirely sure what else is actually reasonable to autoload. Classes, Interfaces, Functions, and Traits make up the scope of first-class code structures, don't they? Autoloading a variable doesn't even make sense to me, and include files are already handled by include[_once]. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecating global + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only
On Thursday, December 09, 2010 4:44:44 am Michael Shadle wrote: On Thu, Dec 9, 2010 at 2:38 AM, Andrey Hristov p...@hristov.com wrote: Yes, as the documentation will mention how to do it, for old applications. For new apps it is easy - pass all the information you need as parameter to the function. It works in other languages, why shouldn't it work for PHP? named parameters would help here. otherwise you wind up with a mess of argument hell. or passing a single array in and then in the function parsing that for the items (which is what I do, sort of a userland way of doing named parameters) but adding more and more parameters to functions over time leads to issues if they do not have default values and if you have to pass say, the 6th parameter, but don't need to pass the rest, etc. It seems like something like this bundled by default could provide an alternative to the super-globals: http://us3.php.net/manual/en/book.http.php Note: I have not actually used said library, just drooled over having a properly abstracted HTTP object for incoming and outgoing communication. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
On Monday, December 13, 2010 10:02:13 am Stefan Marr wrote: However, since traits do not provide any safety provisioning for state, i.e., there is no collision handling for properties, the question is, how do we either promote to use explicit accessors or how do we deal with the inevitable and certainly justified use of properties in one or the other way. Best regards Stefan Thinking about it, I'm not sure that accessors are really a solid solution either. Behavior has to have something to behave on. So whether you have $this-foo or $foo = $this-getFoo(); // Do stuff with $foo $this-setFoo($foo); You still have a dependency that the composing class have either a property named $foo or a pair of (frankly pointless) get/set methods. So either a composing class needs to know about the internal implementation details of a trait (what it calls variables inside of a method) so that it can provide what the trait needs, or a trait needs to be able to carry around its own implementation details. So it seems to me like we can't not let traits carry properties, which means we need to resolve them some how. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Properties
On Monday, December 20, 2010 5:21:08 pm Stefan Marr wrote:
Hi Larry:
On 20 Dec 2010, at 17:04, la...@garfieldtech.com wrote:
Perhaps if both traits use the same variable name, visibility, *and*
default value then there is no error?
There is not fatal error, however, currently there is E_STRICT notice.
I suspect this issue dovetails with the Traits-and-interfaces thread from
earlier.
Ehm, not sure what you want to get at.
The idea of expressing that the composing class needs to satisfy an
interface, or perhaps inherit from a specific class still seems to have a
number of valid use cases. However, there was a single strong opinion
against it, as far as I remember.
I mean, for instance, if you're using an accessor method then you need that
accessor to exist, because you're hard coding its name. If you instead
provide the accessor yourself, the accessor will be hard coded to a variable
name, whether you provide it or not. So either way your trait will die if the
including class doesn't provide some supporting something.
Example:
Trait Foo1 {
function increment() {
// Implicit requirement that a class have a property named foo.
$this-foo++;
}
}
Trait Foo2 {
// Implicit requirement that a class NOT a property named foo.
protected $foo;
function increment() {
$this-foo++;
}
}
Trait Foo3 {
function increment() {
$foo = $this-getFoo();
$foo++;
}
function getFoo() {
// Implicit requirement that a class have a property named foo.
return $this-foo;
}
}
Trait Foo4 {
function increment() {
// Implicit requirement that a class have a method named getFoo().
$foo = $this-getFoo();
$foo++;
}
}
class Test {
use Foo;
}
So one way or another, there is always an implicit requirement placed on the
using class. Implicit requirements suck. :-) If the answer to trait-based
properties is if it breaks when you do that, don't do that (which I don't
fully agree with, in part because of how ugly lots of return-by-ref methods
is), then we have to make the methods as easy as possible. Requiring an
interface is one proposed way to do that.
Reading the RFC over again, I actually see that there is support for abstract
methods in a trait. I suppose that serves a similar purpose of causing a
compile-time error (and thus something much more obvious to be fixed), and
becomes becomes a matter of taste to a degree.
I don't believe the RFC mentions how those resolve in case of collision,
though. If two traits define the same abstract method, does that cause a
collision that needs manual resolution or can the using class just define it
once and thereby support both traits?
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Namespace initializers
On Friday, December 31, 2010 7:56:39 am Nicolas Grekas wrote:
Dear all,
this RFC started by me having a problem on these subjects (not only me
I think) :
- namespaced functions and constants loading, or rather not-autoloading,
- interfaces loading (this time, autoloading).
snip
So, my first proposal for namespaced functions and constants is :
1. Remove namespaced functions and constants at all - promote
namespaced public static methods and class consts instead.
This would fix static code analysis, and the discussion about how to
autoload (I may say how to package) namespaced functions and
constants would vanish. About backward compatibility, who as written
code relying on namespaced functions or constants? They are useless!
Dear god no! Functions are already close to being second-class citizens in
PHP at this point. The project I work on (Drupal) is currently debating how
to leverage function namespaces for our next version and there are several
ways that we could do so effectively; mostly they come down to module ==
namespace, and then a hook (magic function callback) can be placed within a
namespace. That would actually make for clearer code than our current model.
Class == namespace is wrong. Plain and simple. It is a broken assumption
based on broken understanding and the use of them that way is broken. That
approach is utterly useless if you want any sort of flexibility.
My second proposal is :
2. At runtime, when a namespaced identifier is used (lets say
\my\sub\ns\class_interface_constant_or_function), take the namespace
part of the identifier and if any, autoload it as if it were a class,
do not generate any error if the given class name is not found. (ie,
trigger something like class_exists('my\sub\ns', true);).
I am not entirely sure I follow. Are you suggesting that:
use Stuff\Things as Bar;
$foo = new Bar\Baz\Foo()
should trigger:
autoload('Stuff\Things\Baz\Foo');
AND
autoload('Stuff\Things\Baz')?
In the current approach I don't know how you'd properly resolve the namespace
portion of the extended class/function/whatever name. Honestly, combined
with the previous proposal(s) for function autoloading (which I support in
general) it seems to me that we need to have separate but parallel pathways
for autoloading different things; that could lead to better performance, too.
If we can properly separate them I can see a use for clustered autoloading,
certainly, and namespace is a not-unreasonable definition of cluster.
Cons :
- none
- well, one : I don't speak C, so I dont have any patch...
I sadly have the same problem. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] How deep is copy on write?
Hi folks. I have a question about the PHP runtime that I hope is appropriate
for this list. (If not, please thwap me gently; I bruise easily.)
I know PHP does copy-on-write. However, how deeply does it copy when
dealing with nested arrays?
This is probably easiest to explain with an example...
$a['foo']['bar']['baz'] = 1;
$a['foo']['bar']['bob'] = 1;
$a['foo']['bar']['narf'] = 1;
$a['foo']['poink']['narf'] = 1;
function test($b) {
// Assume each of the following lines in isolation...
// Does this copy just the one variable baz, or the full array?
$b['foo']['bar']['baz'] = 2;
// Does this copy $b, or just $b['foo']['poink']?
$b['foo']['poink']['stuff'] = 3;
return $b;
}
// I know this is wasteful; I'm trying to figure out just how wasteful.
$a = test($a);
test() in this case should take $b by reference, but I'm trying to determine
how much of a difference it is. (In practice my use case has a vastly larger
array, so any inefficiencies are multiplied.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How deep is copy on write?
That's what I was afraid of. So it does copy the entire array. Crap. :-)
Am I correct that each level in the array represents its own ZVal, with the
additional memory overhead a ZVal has (however many bytes that is)?
That is, the array below would have $a, foo, bar, baz, bob, narf, poink,
poink/narf = 8 ZVals? (That seems logical to me because each its its own
variable that just happens to be an array, but I want to be sure.)
--Larry Garfield
On Wednesday, January 19, 2011 1:01:44 am Ben Schmidt wrote:
It does the whole of $b. It has to, because when you change 'baz', a
reference in 'bar' needs to change to point to the newly copied 'baz', so
'bar' is written...and likewise 'foo' is written.
Ben.
On 19/01/11 5:45 PM, Larry Garfield wrote:
Hi folks. I have a question about the PHP runtime that I hope is
appropriate for this list. (If not, please thwap me gently; I bruise
easily.)
I know PHP does copy-on-write. However, how deeply does it copy when
dealing with nested arrays?
This is probably easiest to explain with an example...
$a['foo']['bar']['baz'] = 1;
$a['foo']['bar']['bob'] = 1;
$a['foo']['bar']['narf'] = 1;
$a['foo']['poink']['narf'] = 1;
function test($b) {
// Assume each of the following lines in isolation...
// Does this copy just the one variable baz, or the full array?
$b['foo']['bar']['baz'] = 2;
// Does this copy $b, or just $b['foo']['poink']?
$b['foo']['poink']['stuff'] = 3;
return $b;
}
// I know this is wasteful; I'm trying to figure out just how wasteful.
$a = test($a);
test() in this case should take $b by reference, but I'm trying to
determine how much of a difference it is. (In practice my use case has
a vastly larger array, so any inefficiencies are multiplied.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How deep is copy on write?
On Wednesday, January 19, 2011 4:45:14 pm Ben Schmidt wrote: Related: What is the overhead of a ZVal? I'm assuming it's a fixed number of bytes. It seems not, though a zval has a fixed size. What that size is will depend on the compiler and architecture of the system being used, or at least on the ABI. Ah, yes, of course. Oh C... *snip* The zvalue_value union will probably be 8 or 12 bytes, depending on the architecture. The whole struct will then probably be between 14 and 24 bytes, depending on the architecture and structure alignment and so on. *snip* You can figure out what you think the overhead is from that. For a string, arguably the whole structure is overhead, since the string is stored elsewhere via pointer. Likewise for objects. For a double, the payload is 8 bytes, and stored in the zval, so there's less overhead. An integer, with a payload of 4 bytes, is somewhere in between. Hm. OK, so if I'm assuming a 64-bit architecture (most servers these days, I'd think) and just looking for a rough approximation, it sounds like 20 bytes per zval/variable is a not unreasonable estimation. At least close enough for determining the memory overhead of a general algorithm. Thanks again! --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Porting PECL to userspace
Hi all. I'm working with a fellow developer on an experimental project. There are some PECL modules that we want to try and use in an open source project where we cannot guarantee that PECL modules will be available, since it's intended for widespread distribution on both shared hosts and custom hosting. The thought we had was to do a user-space port of the PECL module to include in the project and rely on that. Then if the PECL module is installed, we don't include the library (either via an extension_loaded() check or just relying on autoload) and the PECL implementation gets used instead. Poof, nice speed boost. The questions I have are: 1) Is this even a viable approach? It seems like it, but to my knowledge no one else has done this to any serious extent which makes me wonder if there's a reason the road less traveled is less traveled. 2) Is anyone else doing this? No sense doing it ourselves if someone else already is. 3) What would be the cleanest way to do so? We had the thought of partially automating the process by having PHP auto-generate at the very least the subs of any classes and functions that the module provides. However, when my colleague tried using the same parser as is used for generating documentation he says he got several times as many classes as the manual says the module has. We were using the PECL HTTP module as our sample (http://www.php.net/http). (I don't know the exact details of what he did at the moment.) Is that not a viable approach? Would we be better off using reflection? Is there some other tool we're not aware of? If viable I'd love if this would start a trend, but we'll see where it goes. I know it wouldn't work for all PECL modules, obviously, but I suspect it could work for several, and provide an easy way for different PHP projects to share backend code without needing lots of C developers. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
