> [Убогонький недоязычок]

Странно вопрос тема про «убогенький недоязычок», а содержание про PHP.

А что, есть ещё что-то более убогое?

Я уже нашел

Shallow xml regexp parsing

Говорят, что быстро (на том, с чем ничего не поделаешь).

> А что, есть ещё что-то более убогое?

Превосходная форма здесь не уместна, ибо PHP не убог. Пруфы надо?

я сразу понял о каком языке идет речь и не ошибся.

> я сразу понял о каком языке идет речь и не ошибся.

Молодец, иди возьми с полки пирожок.

> Превосходная форма здесь не уместна, ибо PHP не убог. Пруфы надо?

Эта тема была обсуждена очень много раз. Как шаблонизатор - вполне, как язык общего назначения - слабоват. Учитывая, что веб приложения сейчас становятся всё сложнее и сложнее, то слабость языка становится всё более явной.

http://php.net/manual/en/book.xmlreader.php

> Как шаблонизатор - вполне, как язык общего назначения - слабоват.

Как шаблонизатор — говно. Как мне чибельно и кратко каждый элемент массива обработать заменой по регэкспу, затем сконкатенировать слева и справа со строкой, сджойнить получившееся вместе при помощи еще одной строки и дополнительно приконкратенировать третью строку, если результат предыдущего действия не пуст.

Руби на таких (типичных при генерации страниц из шаблона!) задачах рулит и педалит.

r_asian, в этом топике ты заработал ачивку «успешный тролль». хоть и толстый. однако (покормлю), чаще всего про убогость пхп рассуждают люди, которые не способны ничего толкового сделать ни на одном языке, даже на пхп.

Я толком не знаю. Просто рассуждаю про убогость пхп потому что не способен ничего толкового сделать ни на одном языке. Даже на пхп.

С какого хрена эта белиберда - типичная для шаблонизатора задача, не совсем понятно, но наверно как-то так должно работать, вполне читабельно и кратко.

$result = implode ('glue', array_map(
  function($item) { return 'str1' . $item . 'str2'; }, 
  preg_replace($pattern, $replacement, $source)
));
$result .= !empty($result) ? 'str3' : '';

> вполне читабельно и кратко

/0

Впрочем, кому и свинья — товарищ.

То, что на руби будет короче и красивее - это факт, я и сам частенько пишу на руби автоматизацию всякой мелочевки. Но я не понимаю людей которые хают пхп т.к. во-первых пхп - промышленный стандарт, во-вторых, если сравнивать с руби, пхп на большинстве задач производительнее, в-третьих писать хороший код на пхп вообще не проблема, а то что код более объемный чем на более высокоуровневом языке, ну это как-бы логично, на си еще объемнее будет, и что теперь? си - говно?

А то что ты предложил написать, это не для шаблонизатора задача, шаблонизатор должен только поставлять переменные уметь ветвление, цикл и вызывать хелперы. А всяческое форматирование делается на уровне template preprocessing.

>как язык общего назначения - слабоват

В чем же слабость? И что это за системы такие сложные, которые на php нельзя написать, можно пример?

Содержимое файла:

1
2
3

Запустить в одной консоли:

$f = fopen('file', 'r');
while (true)
{
  if (feof($f))
  {
    sleep(5);
    continue;
  }
  echo fgets($f);
}

после этого в другой консоли:

echo 4 >> file

Продемонстрировать вывод из первой консоли по истечении, скажем, минуты после дополнения файла 'file' командой во второй консоли.

сто комментов о (не)нужности php, а по делу так никто и не написал...

и что будет? мне лень проверять..

>сто комментов о (не)нужности php, а по делу так никто и не написал...

Я таким пользуюсь: https://github.com/Balancer/bors-core/blob/master/inc/xml/xml2array.php

Соответственно, https://github.com/Balancer/bors-core/blob/master/classes/inc/BorsXml.php

Юниттестирование: https://github.com/Balancer/bors-core/blob/master/unittests/classes/bors/test...

Но топик-стартеру это не интересно :)

>и что будет? мне лень проверять.

Да человек открывает неэксклюзивно файл, что-то с ним делает из другого потока и потом удивляется неконсистентности результатов. Сразу видно, что с файлами он и из других языков не работал :)

спасибо, посмотрим.

> Но топик-стартеру это не интересно :)

Топикстрартер не стал ждать пока народ накушается, и нашел более радикальный способ сократить потребление памяти, хотя и не без изменения структуры данных.

А за ссылку все равно мерси. Возможно пригодится.

perl и python с этим как раз без проблем справляются.

proof:

#!/usr/bin/env perl
open(FD, '<a.txt');
while(1)
{
    my $line = <FD>;
    if (!length($line))
    {
        sleep 1;
        next;
    }
    print $line;
}

#!/usr/bin/env python
import time
with open('a.txt', 'r') as fd:
    while True:
        line = fd.readline()
        if not line:
            time.sleep(1)
            continue
        print line

После этого тебе остаётся ещё ответить, чему в Си будет равно i++ + ++i :)

Если в PHP написание on-the-fly парсера лог-файла сводится к повторению мантры open,read_till_eof,close,open,seek,read_till_eof,close,open..., то согласись, что проще уже забить на PHP и написать сразу на сях, «чо уж там». При этом даже вышеприведенная методика глючила безбожно, особенно на моментах logrotate, несмотря на clearstatcache(). Так что не уводи в сторону: как язык для общего применения в силу особенной любви к кэшированию всего-и-вся (в данном случае eof-handle-state) PHP не пригоден. А вот сайтики на нем быстро пишутся, да. Особенно на Kohana.

>Если в PHP написание on-the-fly парсера лог-файла сводится

Это единственное применение системных языков программирования? :)

сводится к повторению мантры open,read_till_eof,close,open,seek,read_till_eof,close,open

Я для подобных целей, вообще, использую gearman. Зачем мне велосипедить? :)

>>Если в PHP написание on-the-fly парсера лог-файла сводится

Это единственное применение системных языков программирования? :)

Могу позвать Капитана, но ты же не оплатишь такси? Однако, с ходу одно из применений отвалилось, и для этой задачи был подобран более другой perl (и да, perlre во всех полях).

>Однако, с ходу одно из применений отвалилось

Прекрасно. И что дальше? :)

#!/usr/bin/env perl
open(FD, '<a.txt');
while(1)
{
    my $line = <FD>;
    if (!length($line))
    {
        sleep 1;
        next;
    }
    print $line;
}

Срань господня, это чо, перл?

Вот ещё более-менее перл:

open(FD,"a.txt");
while(1){
    print if $_ = <FD>;
    sleep 1 if !$_;
}

На реализацию сейчас с#ать. Работает? Работает. Речь о том, что кусок кода «1-в-1» на PHP не заработает, хоть тресни. Даже если s/feof\((.*?)\)/($line = fgets($1)) === FALSE/

> Речь о том, что кусок кода «1-в-1» на PHP не заработает

Скажите, а тексты на естественных языках вы тоже слово-в-слово переводите?

Нет. А почему Вы спрашиваете?

> А почему Вы спрашиваете?

А потому что ваш код на перле и питоне подобен вашему английскому и финнскому, если бы вы писали на русском, а потом слово в слово переводили на эти языки. После чего искренне удивлялись бы, что ваш китайский, полученный таким же методом не понимают, и потому он плох.

Только в вашем случае «родным», похоже выступает С. А английским, финнским и китайским - пистон, перл и пхп соответственно.

Поправочка : C++.

А, кажется, понял. '{' не с той стороны от «\n».

Что этот говнокод должен доказывать? Что вы не осилили tail -f ?

tail -f 'a.txt';

Выхлоп:

PHP Parse error:  syntax error, unexpected T_CONSTANT_ENCAPSED_STRING in /home/user/devel/a.php on line 2

Да, не осилил.

> В чем же слабость? И что это за системы такие сложные, которые на php нельзя написать, можно пример?

На php можно написать всё, это любой Крон скажет. А чего нельзя написать - то просто не нужно. Например декораторы. Или в случае функции, возвращающей массив, получение третьего элемента массива результата без сохранения этого результата во временную переменную (т.е. function_call()[2]). Или неявное преобразование типов типа строки в число. И ещё куча всего. Тут без своего фреймворка (С) уж точно не обойтись.

Поэтому на мой вкус он хорошо не справляется даже с основным своим назначением - вебом. Обсуждать как язык общего назначения вообще не вижу смысла.

И кто-то ещё утверждает, что я якобы толст

Я привёл примеры слабостей языка. Ваша толщина причём?

Например декораторы.

эээ.. религия что ли не позволяет писать декоратор на пхп? Вы уверены что знаете, что такое декоратор? Мне кажется что нет, иначе с чего бы такие глупости писать.

function_call()[2]

ну да, так нельзя, а что, это большая проблема и она накладывает какие-то ограничения на уровень сложности разрабатываемой системы?

если уж сильно стремно во временную переменную сохранять результат, то пишем функцию:

function array_get($index, $source) {
  return $source[$index];
}

Или неявное преобразование типов типа строки в число

А что с ним не так?

f0rk@delta:~$ php -a
Interactive shell

php > $s = '12';
php > var_dump($s);
string(2) "12"
php > var_dump($s * 2);
int(24)

эээ.. религия что ли не позволяет писать декоратор на пхп? Вы уверены что знаете, что такое декоратор? Мне кажется что нет, иначе с чего бы такие глупости писать.

Возможно в 5.3 уже и можно, раньше функции небыли first class members. Если нужен было callable, то вместо него использовалась строка с именем функции. Я имел ввиду конкретный пример декоратора - фукнцию, которая возвращает другую (декорируемую) функцию

ну да, так нельзя, а что, это большая проблема и она накладывает какие-то ограничения на уровень сложности разрабатываемой системы?

Да оно всё небольшая проблема. Просто не очень удобно.

А что с ним не так?

То, что это принципиально неправильно. Старый пример:

[alex:~]$ php -a
Interactive shell

php > $a = array('123' => 'a', 123 => 'b');
php > var_dump($a);
array(1) {
  [123]=>
  string(1) "b"
}