i mentioned a strange issue regarding this topic.. I "solved" it myself, but wanted to discuss if anybody understands the problem behind this.
This query works fine with php 7.0:
$image = (ProductImage::all()->where('productHistory_id', $product->history_id))->first();
And causes a syntax error, unexpected '->' (T_OBJECT_OPERATOR).
This query (without the brackets) works fine with php 7.0 and 5.6:
$image = ProductImage::all()->where('productHistory_id', $product->history_id)->first();
whaaaat?!
Kind regards,
Nico
PHP type checking was eavily revamped between 5.x and 7.x
In both versions the expression:
ProductImage::all()->where('productHistory_id', $product->history_id)
return an instance of a QueryBuilder.
I suspect the presence of the parenthesis cause in earlyer versions of the PHP interpreter to understand it as a scalar value (as in (1+1)+1)) instead of an object value.
This explains why you get an unexpected object operator because PHP 5.X doesn't understand the return of the (...) expression as an object correctly.
This bug is caused exactly by the same parsing error as this one about array dereferencing. It was present on PHP pre 5.4 and was caused by the intereter not detecting the return of a function as an array without using a variable to store it beforehand.
Also on a side note, the parenthesis doesn't change anything as operations on objects are always executed left to right in a statement. May I recommend you to avoid adding useless noise to your codebase?
Related
This snippet of code causes a PHP fatal error in 5.6, but works fine in 7.0 and above. There is no documented change to isset that I could find stating that it works with arrays as constants.
<?php
class Test
{
const A = [1];
}
echo isset(Test::A[0]);
Does anyone know of any documentation stating this was an actual change? Is it safe to use isset with arrays as constants?
PHP 5.6.30 error:
Fatal error: Cannot use isset() on the result of an expression (you can use "null !== expression" instead)
isset() is a language construct and not a function, so perhaps this paragraph (from http://php.net/manual/en/migration70.incompatible.php) applies:
PHP 7 now uses an abstract syntax tree when parsing source files. This
has permitted many improvements to the language which were previously
impossible due to limitations in the parser used in earlier versions
of PHP, but has resulted in the removal of a few special cases for
consistency reasons, which has resulted in backward compatibility
breaks.
Hi i have a new server runing php 5.4 on rackspace and there is errors con my code
i cannot do this becouse its giveme a error:
if(empty($basics->conversions*100) || empty($basics->activations))
this is the problem: ($basics->conversions*100);
i have to do $vr = $basic->conversions*100;
if(empty($vr)) but i have this all over my code and i cannot fix it
Parse error: syntax error, unexpected '*', expecting ')' in ***
the other error is when using a function returning an array and accesing that array insted of assign it to a variable example:
getReports($date, $todate)['utm'];
this gives me error.
but if i do:
$arrReportes = getReports($date,$todate);
$arrReports['utm'];
Works perfectly why ? can you helpme i cannot find any on google
From http://php.net/manual/en/function.empty.php
Prior to PHP 5.5, empty() only supports variables; anything else will
result in a parse error. In other words, the following will not work:
empty(trim($name)). Instead, use trim($name) == false.
This explains why your first error is occurring - empty() just doesn't let you pass an expression to it like you are doing in the version of php you said you are running (5.4).
The second error should really have been put in a separate question. In theory what you are trying to do should be possible since php 5.4 -
As of PHP 5.4 it is possible to array dereference the result of a
function or method call directly. Before it was only possible using a
temporary variable.
(from http://php.net/manual/en/language.types.array.php)
- but you claim to be running 5.4 so I'd imagine there's an issue somewhere else. I'd double check the version of php you're running, and ensure your code isn't at fault there too. You didn't specify what error you were getting, so it could well be that the returned array is null, or anything.
I have a Form object $form. One of its variables is a Field object which represents all fields and is an array (e.g $this->field['fieldname']). The getter is $form->fields().
To access a specific field method (to make it required or not for example) I use $form->fields()['fieldname'] which works on localhost with wamp but on the server throws this error:
Parse error: syntax error, unexpected '[' in (...)
I have PHP 5.3 on the server and because I reinstalled wamp and forgot to change it back to 5.3, wamp runs PHP 5.4. So I guess this is the reason for the error.
How can I access an object method, which returns an array, by the array key with PHP 5.3?
Array dereferencing is possible as of PHP 5.4, not 5.3
PHP.net:
As of PHP 5.4 it is possible to array dereference the result of a function or method call directly. Before it was only possible using a temporary variable.
Array dereferencing as described in the question is a feature that was only added in PHP 5.4. PHP 5.3 cannot do this.
echo $form->fields()['fieldname']
So this code will work in PHP 5.4 and higher.
In order to make this work in PHP 5.3, you need to do one of the following:
Use a temporary variable:
$temp = $form->fields()
echo $temp['fieldname'];
Output the fields array as an object property rather than from a method:
ie this....
echo $form->fields['fieldname']
...is perfectly valid.
Or, of course, you could upgrade your server to PHP 5.4. Bear in mind that 5.3 will be declared end-of-life relatively soon, now that 5.5 has been released, so you'll be wanting to upgrade sooner or later anyway; maybe this is your cue to do? (and don't worry about it; the upgrade path from 5.3 to 5.4 is pretty easy; there's nothing really that will break, except things that were deprecated anyway)
As mentioned array dereferencing is only possible in 5.4 or greater.
But you can save the object and later on access the fields:
$fields=$form->fields();
$value=$fields['fieldname']
...
AFAIK there is no other option.
We recently had a disaster and had to move our php web application from PHP Version 5.2.6-1+lenny16 to PHP Version 5.3.3-7+squeeze15 and found a seemingly important difference.
In our application, there were instances where we incorrectly called an array's index using object syntax:
echo $array->index;
However, 5.2.6 seemed to forgive this, and correctly treat it as if $array['index'] was written.
Upon further testing, what 5.2.6 is specifically doing is disagreeing with 5.3.3 as to whether $array->index is empty();
Here is the test code I've run on both servers:
<?php
echo phpversion() . '<br>';
$array = array(
'x' => 1,
'y' => 2
);
if (!empty($array->x))
{
echo "not empty";
}
else
{
echo "empty";
}
?>
Here are the two different outputs:
5.2.6-1+lenny16
not empty
5.3.3-7+squeeze15
empty
Naturally, there are now a few outbreaks of broken functionality because we were never alerted to these errors during development. Is there a way we can configure php 5.3 to permit this incorrect syntax while we take a bit more time to find all the incorrect instances of it?
I don't think it's a configuration issue, is it? Was something changed in the way empty() works in between versions?
I just have put your example code to a general test across PHP versions (test) and it shows that you are correct, there are differences:
From PHP 5.0.0 up to 5.2.11 (and also early 5.3.0 to 5.3.1), this "undefined property" was reported as not empty which does qualify as a flaw or bug.
The related change in 5.2.12 (17 Dec 2009) was (ref):
Fixed bug #50255 (isset() and empty() silently casts array to object). (Felipe)
Technically this is not a backwards incompatible change from PHP 5.2 to 5.3 because it was a flaw in both branches and also fixed in both. Those are harder to spot if you migrate, because the standard migration guide does not cover them. Instead you need to go through the changes of the software and look for notes and references to tickets.
So to answer your question: This is a configuration issue because the PHP version used counts as configuration. You changed the configuration and then you had the issue.
Also as the report shows, this is limited to empty() and isset(), not general object/array access. As you can imagine, if that would have been the case, you would have found much more reference about it.
This is similar to Can PHP instantiate an object from the name of the class as a string?.
I'm using propel orm with PHP 5.2.17, and I want to store the name of a query class in the database, say "AuthorQuery", then use it to get a query object. There may be a different way to do this with propel, avoding the ::create() factory method. That solution would be welcome, but I'd rather to know if this is even possible with php (I won't be terribly surprised if the answer is "It's not").
Here's the problem. This will work:
$author_class = "Author";
$author = new $author_class();
Using the new keyword a string will get interpreted as the class name.
But I get syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM (that's referring to the ::) when I try to do it using a factory constructor instead:
$author_query_class = "AuthorQuery";
$author_query = $author_query_class::create(); // syntax error at the ::
Do I need an extra $ or something?
It turns out, this is not an issue for PHP 5.3+
Works exactly the way you describe (as far as I remember) with PHP5.3. However, if you still use 5.2, you can use reflection
$x = new ReflectionClass($author_query_class);
$author_query = $x->getMethod('create')->invoke(null);
Or just
$author_query = call_user_func(array($author_query_class, 'create'));
Worth to mention, that this is "much magic" and it will get hard to understand, what happens, when you have many of such constructions.
$author_query=call_user_func("$author_query_class::create");
This has to do with this line:
$author_query_class::create();
It is because (as quoted from the book PHP Master):
The double colon operator that we use for accessing static properties
or methods in PHP is technically called the scope resolution operator.
If there’s a problem with some code containing ::, you will often see
an error message containing T_PAAMAYIM_NEKUDOTAYIM. This simply refers
to the ::, although it looks quite alarming at first! “Paamayim
Nekudotayim” means “two dots, twice” in Hebrew.
You can do something like this in PHP 5.3 and more support is is on the table for PHP 5.4. Before PHP 5.2 you may have to use something like the other answers provided or , gulp, eval().