PHP и с чем его едят....

[PainKiller]

Я специально отметил ! это слово. Если Вы внимательно посмотрите исходный код PHP, Вы поймете почему. При выполнении PHP 5.x компилирует исходный код в байт-код, который затем выполняется на виртуальной машине Zend VM. Режим потоковой интерпретации в php был упразднен с версии 4.0
Для примера, вами-же любимый перл с 6й версии компилирует исходник в байт-код для parrot VM.

Простите меня за резкость, но Вы просто не знаете основ самого языка.

Именно потому я PHP, как язык, и забросил, это было до того, как 5.0 пошло в массы.

Даже не так. PHP перестал меня удовлетворять как инструмент для достижения определенного профита. В нутре его ковыряться смысла не вижу, интересно, ооп до ума довели?)
Насчет Perl.
В 5 перле тоже можно компилировать программки в байт код для машины, эта штука называется perlcc.
Ну и решающим фактором в выборе были мощные регулярные выражения, ну и, естественно, perlcritic и use strict;
Ну и насчет perl6. Я сомневаюсь, что это будет прорыв. Интересная реализация, бесспорно, НКА, их встроили прямо в язык, активируются простым ключом. Memoize(производительность) можно подключать в 5 перле, для ряда моих задач он гораздо нужнее, чем php.
1;
Ну и еще, как следствие работы с перлом, впадло писать много кода, по той же причине яву и забросил.
и Вы меня простите за резкость, но утверждать, что перл компилируется в байт код только с 6 версии - тоже говорит о незнании основ языка
Будем дальше офтопить?

 

[ostapoff]

Читайте внимательно - в byte-code для Parrot VM. perlcc производил компиляцию perl в с, затем gcc компилировало его в asm. Но это не касается модулей подключаемых через use. Так что особого смысла в этой компиляции не было. perl5 выполнял-же код в режиме потоковой интерпретации.

PainKiller, с Вами неинтересно дискутировать, Вы невнимательно читаете, что Вам пишут, вынуждая собеседника повторять по 2 раза одно и то-же.

 

[PainKiller]

Ок, но у Perlcc была возможность компилить в байткод, perlcc -MO=Bytecode, оно генерило .bin файл, насколько я знаю, он был платформозависимым.
use base qw/LibName/;
Позволяет делать полный экспорт, грубо говоря, наследование, так вот, оно сгребается в кучу.
Действительно, насчет попугайчега мог и не заметить.

You must be registered for see links

Это как вариант ВМ.
К сожалению, по "потоковой интерпретации" man и монастырь молчат, но, насколько я знаю, perl5 таки использует прекомпиляцию, проверяя синтаксис в отдельном потоке, но в конечном итоге, все-таки используется байт код, если это называется "потоковая интерпретация", то ок.
Мне тоже не нравится такая дискуссия.

 

[ostapoff]

Мы как-то плавно ушли от темы дискуссии – преобразования типов в PHP.

На счет perlcc, на моей памяти, все что мало-мальски серьезное я им пробовал компилировать, просто не работало или вылетало во время работы. Но, как говориться, о покойниках принято говорить либо хорошо, либо никак. Кажется, perlcc уже лет 5 как похоронили…

 

[PainKiller]

Да, только 3 года, его, по-моему, из перла 5.8 или 5.9 исключили, много моего кода работает благодаря perlcc + Redis, полезная штука, потому приходится пользоваться старым перлом.
Для нормальной компиляции надо было использовать либо Bytecode, либо использовать perlcritic, use strict и DynaLoader. Всегда, кстати, не хватало в пхп параноидальности интерпретатора, ругается он мало =)

 

[ostapoff]

error_reporting(E_ALL | E_STRICT) делает PHP очень параноидальным. В PHP область видимости переменных ограничена текущей функцией и доступ в более высокий уровень отсутствует по-умолчанию (только через global или using). В perl-e все с точностью до наоборот, программист вынужден использовать my, чтобы локализовать область видимости.

 

[kattykatty_]

Как показывает прочтение статьи, trim не должна принимать null, но принимает, а по уму должна была бы ругаться.

Из ваших высказываний я сделала вывод, что реализация функции trim() в php такая, что передаваемые ей типы данных object, resource, array вызовут Warning и не прекратят исполнение скрипта, а integer, float, boolean и null будут приведены к типу string вам кажется не удачной.
А реализация trim(), при которой переданный ей любой тип данных, кроме string даст ошибку, корректной.
В связи с чем у меня к вам вопросы.
1. Правильно ли я поняла вашу мысль и если да, то не могли бы вы на примерах кода доказать, что вторая (более строгая) версия реализации trim удобней ?
2. Какую ошибку вы считаете должен выдавать php во второй реализации (warning, fatal error или др)?

 

[PainKiller]

error_reporting(E_ALL | E_STRICT) делает PHP очень параноидальным. В PHP область видимости переменных ограничена текущей функцией и доступ в более высокий уровень отсутствует по-умолчанию (только через global или using). В perl-e все с точностью до наоборот, программист вынужден использовать my, чтобы локализовать область видимости.

Это очевидно, НО, error_reporting(E_ALL), как понятно из самого названия функции, просто выводит больше, а нотис, как известно, за ошибку не считается. Я говорю про одно, а мне в ответ совершенно другие, очевидные вещи.
Заметьте, use strict не просто выводит ошибки, а не дает perl выполнить кривое поделие, аналог error_reporting в перле - -w или -W ключи запуска, к ним же, кстати, можно добавить проверку на загрязненность, но не суть.

 

[PainKiller]

Из ваших высказываний я сделала вывод, что реализация функции trim() в php такая, что передаваемые ей типы данных object, resource, array вызовут Warning и не прекратят исполнение скрипта, а integer, float, boolean и null будут приведены к типу string вам кажется не удачной.
А реализация trim(), при которой переданный ей любой тип данных, кроме string даст ошибку, корректной.
В связи с чем у меня к вам вопросы.
1. Правильно ли я поняла вашу мысль и если да, то не могли бы вы на примерах кода доказать, что вторая (более строгая) версия реализации trim удобней ?
2. Какую ошибку вы считаете должен выдавать php во второй реализации (warning, fatal error или др)?

Ок, вот для примера, реализация trim, как ее вижу я. Писать все лениво, если можно допилить условие:

<?php
error_reporting(E_ALL);
function _trim($str)
{
	if($str == '' || !isset($str))
	{
		trigger_error("first param must not be null or empty string", E_USER_NOTICE);
		//return null по желанию
	}
	else
		return trim($str);
}
function _trim2($str)
{
	if($str == '' || !isset($str))
		return null;
	else
		return trim($str);
	
}
echo '<pre>';
echo 'trim';
$str=trim(null);
var_dump($str);
echo '_trim';
$str2=_trim(null);
var_dump($str2);
echo '_trim2';
$str3=_trim2(null);
var_dump($str3);
echo '</pre>';

?>

Ну вот _trim - первый вариант
_trim2 - второй вариант. Это то, как я вижу их работу, это, так сказать, чтоб поточнее передать свою мысль.

Мне не нравится именно то, что оно из null делает строку, т.е. из ничего строку. Думаю, моя точка зрения ясна и она, кстати, не претендует на истину в первой инстанции.

 

[ostapoff]

E_NOTICE предупреждает девелопера о потенциальных ошибках, грязном коде, опечатках, плохом стиле и неинициализированных переменных в частности. must have для разработчика.

На счет trim – Вы пытаетесь языку навязать сильную типизацию. Это просто не PHP-way.