Hi,
I wouldn't really worry about the ternary operator too much. These kinds of
micro optimizations really only appear to make a difference in contrived
benchmarks and usually aren't the norm in real life applications. However,
with that said, an optimization is an optimization. Optimizations like
Time:
$arr = range(0, 100); // 0.6367609500885
$foo == true ? $foo = $arr : NULL; // 3.0994415283203E-06
if (true) $foo = $arr; else $foo = NULL; // 2.8610229492188E-06
PHP 5.1.6
Olafur Waage
On Sun, Dec 14, 2008 at 9:30 PM, David Grudl wrote:
>
> Původní zpráva
> Od: Ilia
Původní zpráva
Od: Ilia Alshanetsky
While it is slower due to the use of temp vars, in my experience
unless you have a few hundred operations involving ternary operator
you cannot even see the difference. Even then there are typically way
more important areas of code that ne
While it is slower due to the use of temp vars, in my experience
unless you have a few hundred operations involving ternary operator
you cannot even see the difference. Even then there are typically way
more important areas of code that need to be optimized. The only time
you can really tel
On Sun, Dec 14, 2008 at 8:06 PM, David Grudl wrote:
> Hello,
>
> ternary operator is very nice syntactic sugar...
>
> $foo = $cond ? $bar : $baz;
>
> ...but it may slows down scripts. When $bar is array or relative big string,
> it is better to aviod sugar and use if:
>
> if ($cond) $foo = $ba
Původní zpráva
Předmět: [PHP-DEV] Removing basic types from our JSON parser
Od: theta...@php.net (Uwe Schindler)
Komu:
Datum: 14.12.2008 10:40
var foo = ;
will always work. The only question is what sort of variable foo will
end up being. The
Hello,
ternary operator is very nice syntactic sugar...
$foo = $cond ? $bar : $baz;
...but it may slows down scripts. When $bar is array or relative big
string, it is better to aviod sugar and use if:
if ($cond) $foo = $bar; else $foo = $baz;
and reference counting will be used.
I do
It also says:
5. Generators
A JSON generator produces JSON text. The resulting text MUST
strictly conform to the JSON grammar.
It says "JSON text" not JSON-text. There is no errata about this, so
intended or not, PHP follows the spec.
Rob
Scott MacVicar wrote:
The JSON grammar explici
Le dimanche 14 décembre 2008 à 00:39 -0800, Rasmus Lerdorf a écrit :
>
> var foo = ;
>
>
> will always work. The only question is what sort of variable foo will
> end up being. The RFC says we have to wrap basic types in an array or
> object, while currently we le
>
> var foo = ;
>
>
> will always work. The only question is what sort of variable foo will
> end up being. The RFC says we have to wrap basic types in an array or
> object, while currently we let the basic types through without the
> wrapper.
He problem her eis:
mike wrote:
> On Sun, Dec 14, 2008 at 12:39 AM, Rasmus Lerdorf wrote:
>
>> Eh? Read what you wrote there. If json wasn't pure javascript, how in
>> the world would eval() work on it?
>
> Sorry. I guess I meant it didn't execute by itself, but needed to be
> interpreted using something like eva
On Sun, Dec 14, 2008 at 12:39 AM, Rasmus Lerdorf wrote:
> Eh? Read what you wrote there. If json wasn't pure javascript, how in
> the world would eval() work on it?
Sorry. I guess I meant it didn't execute by itself, but needed to be
interpreted using something like eval and/or thrown into a v
mike wrote:
> Do you mean a json_parse in javascript (like a better eval() I assume)?
> Thats what we were doing. Json is not supposed to be pure javascript
> either, but a serialized representation of variables like php's
> serialize(). So I would not expect a json string to be usable without
> us
Do you mean a json_parse in javascript (like a better eval() I
assume)? Thats what we were doing. Json is not supposed to be pure
javascript either, but a serialized representation of variables like
php's serialize(). So I would not expect a json string to be usable
without using eval or so
14 matches
Mail list logo
