Re: PHP - всі за і проти
Ви маєете рацію.
Ви не увійшли. Будь ласка, увійдіть або зареєструйтесь.
Ласкаво просимо вас на україномовний форум з програмування, веб-дизайну, SEO та всього пов'язаного з інтернетом та комп'ютерами.
Будемо вдячні, якщо ви поділитись посиланням на Replace.org.ua на інших ресурсах.
Для того щоб створювати теми та надсилати повідомлення вам потрібно Зареєструватись.
Український форум програмістів → PHP → PHP - всі за і проти
Сторінки Попередня 1 2 3 4 5 6 Наступна
Для відправлення відповіді ви повинні увійти або зареєструватися
В документації по функції glob написано що
Returns an array containing the matched files/directories, an empty array if no file matched or FALSE on error.
ДАлі:
if ($files = $this->agrExists($uid . '_' . $name) != FALSE){ foreach($files as $fileNames){…}}
Я очікував що, якщо фіункція поверне не FALSE, то в змінній $files буде масив, але ні. Там буде TRUE. Треба писати отак:
$files = $this->agrExists($uid . '_' . $name) if ($files != FALSE){…}
В такому випадку, якщо функція поверне масив то в змінній $files таки буде масив. Я чогось не розумію.
Оператор = має нижчий пріоритет, ніж != — відповідно, спершу відбувається порівняння з FALSE, а вже потім результат цього порівняння присвоюється змінній. Просто візьміть у дужки частину, де відбувається присвоєння:
if (($files = $this->agrExists($uid . '_' . $name)) != FALSE){
foreach($files as $fileNames){…}}
Погоджуюсь з P.Y., але там справа навіть не в пріоритетності, бо присвоєння відбувається справа на ліво завжди. Якщо праворуч у нас є вираз
$this->agrExists($uid . '_' . $name) != FALSE
то абсолютно логічно, що він поверне логічне значення для змінної $files
$a = false;
$b = true;
$c = $a XOR $b;
var_dump($c); // FALSE
$a = true;
$b = false;
$c = $a XOR $b;
var_dump($c); // TRUE
$a = false;
$b = true;
$c = ($a XOR $b);
var_dump($c); // TRUE
Я так розумію перша змінна має більший приорітет ?
Якби XOR в першому прикладі був обчислений, то там було б TRUE. Може у присвоєння вищий пріорітет?
І тут те саме:
$a = true;
$b = true;
$c = $a XOR $b;
var_dump($c); //true
Розгляньте такий варіант:
$a = true;
$b = false;
var_dump($c = $a XOR $b); // true
$a = false;
$b = true;
var_dump($c = $a XOR $b); // true
Стосовно прикладу з лол, то видається Notice що не знайдено константи "лол", але цей напис приймається за рядок, також особливих проблем не бачу.
Розгляньте такий варіант:
$a = true; $b = false; var_dump($c = $a XOR $b); // true $a = false; $b = true; var_dump($c = $a XOR $b); // true
Стосовно прикладу з лол, то видається Notice що не знайдено константи "лол", але цей напис приймається за рядок, також особливих проблем не бачу.
А ви часом не знаєте, чому така дивна поведінка у простого присвоювання?
А ви часом не знаєте, чому така дивна поведінка у простого присвоювання?
Ось цей випадок з оператором xor - це якраз питання в пріоритетності оператора. Не бачу тут складності.
Стосовно константи лол, то це дійсно неочевидна поведінка, але достатньо знати що PHP нестрого-типізована мова, та побачити отакий приклад, щоб надалі це не було проблемою з вгадуванням результатів.
Тобто можливість створення таких змінних це також нормально ?
${'!@#$%^&*()_+'}
Я згідний з @VTrim кому потрібні такі приколи, я хз
${'!@#$%^&*()_+'}
Ніколи не юзав таку штуку
Доречі, зараз продивившись всі варіанти пріоритетності операторів, бачу що все таки і приклад
$files = $this->agrExists($uid . '_' . $name) != FALSE
як і казав P.Y. - це теж, все таки, питання в пріоритетності.
Змінна з довільним іменем ${'!@#$%^&*()_+'}, думаю це теж нормально.
quez написав:А ви часом не знаєте, чому така дивна поведінка у простого присвоювання?
Ось цей випадок з оператором xor - це якраз питання в пріоритетності оператора. Не бачу тут складності.
Стосовно константи лол, то це дійсно неочевидна поведінка, але достатньо знати що PHP нестрого-типізована мова, та побачити отакий приклад, щоб надалі це не було проблемою з вгадуванням результатів.
Погано зробили, тупо. Цьому є якесь лоічне пояснення?
Погано зробили, тупо. Цьому є якесь лоічне пояснення?
Зараз продивився вікі, бачу що ці мови народились приблизно коли я ще ходив у 9 клас (в 1995 році)... Щоб в PHP було багато "тупого", то вона б не займала місце в top-5 серед найпоширеніших мов програмування
quez написав:Погано зробили, тупо. Цьому є якесь лоічне пояснення?
Зараз продивився вікі, бачу що ці мови народились приблизно коли я ще ходив у 9 клас (в 1995 році)... Щоб в PHP було багато "тупого", то вона б не займала місце в top-5 серед найпоширеніших мов програмування
Популярність мови та її продуманість не мають між собою однозначного зв'язку. Популярність PHP та непопулярність Haskell це чітко демонструють.
Але я зовсім не про те. Придумайте приклад, де ви використаєте нижчий пріорітет xor'а в порівнянні з присвоєнням.
Популярність мови та її продуманість не мають між собою однозначного зв'язку. Популярність PHP та непопулярність Haskell це чітко демонструють.
Я думаю навпаки. У мові PHP багато всяких недоліків, але якщо б ці недоліки зразу виправлялись, то мабуть і популярність би була менша, так як швидко ваш код ставава несумісний.
Також у PHP дуже багато і перевага, тому і популярність досить висока. + Сегмент )
PHP does a terrible job of providing detail in error messages. For example:
$ cat quotes.php
<?php$string = "welcome to my personal home page;
# a fake example; just imagine some lenghty code here
if ($page_id == 0) {
render_home_page();
} elsif ($page_id == 1) {
render_contacts_page();
} elsif ($page_id == 2) {
render_about_page();
} elsif ($page_id == 3) {
render_services_page();
} elsif ($page_id == 4) {
render_weather_page();
} elsif ($page_id == 5) {
render_news_page();
}print "thank you for visiting!";
$ php quotes.php
Parse error: syntax error, unexpected T_STRING in quotes.php on line 20
PHP identifies the issue on line 20, while the real mistake is on line 3. In contrast, here's what Perl does in the same situation:
$ perl quotes.pl
Bareword found where operator expected at quotes.pl line 20, near "print "thank"
(Might be a runaway multi-line "" string starting on line 3)
(Do you need to predeclare print?)
Unquoted string "visiting" may clash with future reserved word at quotes.pl line 20.
syntax error at quotes.pl line 20, near "print "thank you "
Can't find string terminator '"' anywhere before EOF at quotes.pl line 20.Note especially that second line not only points the developer to the correct location, but also describes exactly what it thinks is happening.
Рядок №20 це там де print "thank you for visiting!";
Осб іще вкусняшка — Segfault during deep recursion
Deep recursion during php clone will cause a segfault:
$ php -r 'class A { public function __clone() { clone $this; } } clone new A();'
Segmentation faultThis can happen during cloning of large or self-referential data structures, such as linked lists. This was filed as a bug in 2009, but marked as "not a bug" because "Infinite recursion crashes. There's no fix for that."
In PHP versions before 5.3, this happens for any deep recursion:
$ php -r 'function a(){ global $i; $i++; print "$i\n"; a(); } a();'
(snip a few thousand lines...)
19162
19163
19164
19165
19166
Segmentation fault
Написано про PHP до версіїї 5.3, але в мене PHP 5.5.9-1ubuntu4.14 (cli) (built: Oct 28 2015 01:34:46 і
22756
Segmentation fault