I don't think your comment on Overflows - "Zend is by definition a correct implementation" - is necessarily right - elsewhere we're definitely looking at Zend having to change their implementation, right? Great article, BTW.
Critiquing Facebook's new PHP spec
51–60 of 70 posts
Re: Critiquing Facebook's new PHP spec
#52"One other thing they specified is that array cursors are internal.... This would manifests if a new PHP implementation wanted to use a different threading model: would two threads looping through the same array use the same cursor? Sounds pretty racy." Is it even worth it to leave room for a threaded PHP? At this point that would de facto be another language anyhow... the changes required to add threading to a langu…
I'm of the opinion that languages around the 10 year mark (which PHP is obviously well past) really ought to focus on becoming the best X they can be, rather than chasing the tail lights of constantly-moving best practice. Would that include not adding: * Anonymous functions and closures * Namespaces * Late static binding * Dynamic dispatching to static methods * Rackup/SimpleHTTPServer-like web server * "finally" in…
[deleted]
Re: Critiquing Facebook's new PHP spec
#53Im sorry for my English.
All rotating around zend, refs, memory, these variable's copy...
Good question: Who cares about Zend?
I monitor my application under kcachegrind and xdebug/tracefile-analyser.php: in generally its array-copy operations, classes load, require/include, and strings and its definitely are slow. Why no types like: lists, tuples, ascii-string (I think it fastest, than unicode or any latin)? Array its multi-paradigm? Ok. Nice YAGNI implementation.
I try prevent pass arrays and replace it with ArrayObject or stdClass or any custom object because objects its reference by defenition. It help improve memory consumption but not so effective.
I think PHP needs improve internal components first and also Zend that nailed down to PHP.
But its good of course that spec under public discussion, hope this help improve language.
Re: Critiquing Facebook's new PHP spec
#54I don't think your comment on Overflows - "Zend is by definition a correct implementation" - is necessarily right - elsewhere we're definitely looking at Zend having to change their implementation, right? Great article, BTW.
No, the spec leaves implementing it open. Something I'm trying to change as the behaviour in the spec is wrong.
Re: Critiquing Facebook's new PHP spec
#55> describe the difference between
$a = new Point(1, 3)
and
$a =& new Point (1, 3)
Answer: I forget! I think it’s that the next assignment to “$a` will do something odd, but honestly I don’t remember the subtleties.
So what is the difference exactly?
Re: Critiquing Facebook's new PHP spec
#56When I read the new PHP spec, I threw up in my mouth after I saw that empty("0") was a special case of empty that returned TRUE. I know that's how PHP normally works, but that doesn't really make my mouth taste any better.
The thing you have to understand about PHP, is it's meant to easily work in a world where every value is in a string. You get strings from the browser, you get strings from the database, and strings from the file system. It was expected that these strings contain numbers and that you should be able to rationally use them as numbers without conversion. So "10" > "5" returns true in PHP where as that would be false in…
> You get strings from the browser
Really? I thought browsers sent HTTP requests.
> you get strings from the database
Really? I thought databases returned tables, ie. ordered collections of rows with individually-typed columns.
> and strings from the file system.
Really? I thought filesystems returned streams of bytes.
Just because lots of values can be represented by strings, doesn't mean they are strings. "X is a string" is the cause of:
* XSS vulnerabilities: "HTML is a string" and "user input is a string"; why not concatenate them?
* SQL(/shell/eval/etc.) injection vulnerabilities: "SQL queries are strings" and "user input is a string"; why not concatenate them?
* Multilingual issues: "byte streams are strings"
* Malformed requests/responses (ie. 'message not understood', invalid markup, etc.): "requests/responses are strings"
I know you're stating the rules of PHP, rather than a personal opinion, but I think it's important to reiterate this point whenever "x is a string" comes up. Strings are an implementation detail which should be abstracted over. After all, strings themselves are just an abstraction over bytes/words.
Re: Critiquing Facebook's new PHP spec
#57Earlier quoted context omitted.
EDIT: Brain fart; don't use this. See comments below. Just use the following if you really want to account for strings containing the number 0. (!isset($var) || $var === false); Note the triple equals sign.
If you really want to test for empty strings where $a is defined just use: if ($a == "") { ... } Empty is merely the function equivalent of the not (!) operator. The semantics are exactly the same except for the handling of undefined variables. It's not something one should use except if you're expecting to deal with undefined variables.
> Empty is merely the function equivalent of the not (!) operator.
Nope! "empty" is an operator too:
var_dump(array_map('empty', [null, '', 5, false]));
PHP Warning: array_map() expects parameter 1 to be a valid callback, function 'empty' not found or invalid function name
NULL
Re: Critiquing Facebook's new PHP spec
#58Earlier quoted context omitted.
I'm of the opinion that languages around the 10 year mark (which PHP is obviously well past) really ought to focus on becoming the best X they can be, rather than chasing the tail lights of constantly-moving best practice. Would that include not adding: * Anonymous functions and closures * Namespaces * Late static binding * Dynamic dispatching to static methods * Rackup/SimpleHTTPServer-like web server * "finally" in…
"Would that include not adding:" A whole bunch of completely standard features to add to a mutable-state dynamic scripting language, almost each and every one of which had been successfully added to a mutable-state dynamic scripting language before PHP did it? Of course not. (I'm not sure about that last one, though I suspect one could find a version of Perl early into its reference experimentations that would have a…
> Even today, I'm not sure if a function that returns a list (not list ref) can be directly dereferenced into via [] notation.
Unless it's changed very recently, you cannot; you have to wrap it in an arrayref, e.g.
[returnsAList()]->[0]Re: Critiquing Facebook's new PHP spec
#59Good to finally see a PHP spec! You might also be interested in a formal semantics for PHP which has been presented today at the ECOOP'14 conference in Uppsala, Sweden. Details can be found at www.phpsemantics.org. As I wrote before, I wish we had this spec a couple of years before - our life would have been so much easier! :)
Re: Critiquing Facebook's new PHP spec
#60Earlier quoted context omitted.
The thing you have to understand about PHP, is it's meant to easily work in a world where every value is in a string. You get strings from the browser, you get strings from the database, and strings from the file system. It was expected that these strings contain numbers and that you should be able to rationally use them as numbers without conversion. So "10" > "5" returns true in PHP where as that would be false in…
> You get strings from the browser Really? I thought browsers sent HTTP requests. > you get strings from the database Really? I thought databases returned tables, ie. ordered collections of rows with individually-typed columns. > and strings from the file system. Really? I thought filesystems returned streams of bytes. Just because lots of values can be represented by strings, doesn't mean they are strings. "X is a s…
Much of the reasons for PHP being stringly typed are historical. For example, extremely old database drivers used to stringify everything so you didn't get individually-typed columns. An HTTP request, specifically an encoded GET or POST, all values from the browser are strings. A file system is a stream of bytes, but many common web file formats stringify all values (JSON, XML, INI, etc).
> Strings are an implementation detail which should be abstracted over.
That's exactly what PHP does -- PHP doesn't care what representation a value has. But that is also then the source of it's strangeness.