Меню
Что нового?

Собираем вопросы авторам PHP - они ответят на PHPConf 2008

fisher

fisher

накатила суть
вопрос имел бы смысл если мы стали говорить, например, о JIT-компиляции.

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

predator

web designer
Автор оригинала: fisher
вопрос имел бы смысл если мы стали говорить, например, о JIT-компиляции.

но на самом деле пока проще потратить какое-то время на изучение того, как сделать модуль для пхп на си. ведь понятно, что абсолютно весь php-код в си-модули переводить совсем не надо, это делается для сервисов, или какого-нибудь ядра фреймворка или шаблонизатора, а стоимость владения приложением, где бОльшая часть наиболее вероятно изменяемого кода написана на пхп - она ниже, боюсь, просто в разы.
Нажмите для раскрытия...
ядро фрэймворка и библиотеки это львиная часть кода в проекте (покрайней мере у меня так )))
модули и шаблоны обычно занимают ничтожную часть от общего объёма кода
вот все эти библиотеки и хорошо иметь в виде откомпилированного модуля пхп
а так как библиотеки тоже постепенно видоизменяются и дописываются, то было-бы неплохо
разработку вести на пхп а в итоге получать пхп-модуль, например на основе релизов движка.

я вот не понимаю в чём сложность - пхп разбирает код каким-то образом
и исполняет его в последствии через свои сишные либы
для каждой конструкции пхп есть свой аналог на си
вобщем разговоры о фантазиях и бессмысленности мне кажутся некорректными

если-бы такое было возможно, подавляющее большинство средних и больших проектов писались-бы на пхп
.нет с явой нервно курили-б в сторонке (т.к. появилась бы расширять пхп за счёт написанных народом модулей).
скорость разработки на пхп + скорость работы быстро скомпилированных библиотек и ядра системы = решающее преимущество

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

chown

Новичок
PHP != C++. Сомневаюсь, что скорость работы модуля написанного на PHP, затем перегенериного на С++ и, наконец, скомпилиного будет сколько угодно сильно отличаться от скорости работы только интерпретируемого кода PHP. Ведь логика работы движка PHP останется. Можно написать тоже самое на С++, но код у вас будет другой совершенно.
Чтобы далеко не забегать, сравните, что такое переменная типа int в PHP и C++, а затем сравните реализацию классов.
 

Rashkin

Новичок
Для меня в PHP самый большой недостаток

Нет Множественного наследования.
В описании функции агрегации почему то написано, что можно использовать только на свой страх и риск.
использовать ее конечно же сразу расхотелось. хотя и не понятно в чем проблема.

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

http://ru2.php.net/manual/en/intro.objaggregation.php
механизм связывания в принципе тоже удобен
 
crocodile2u

crocodile2u

http://vbolshov.org.ru
Rashkin
Подобие mixin можно реализовать с помощью агрегации + перегрузки методов

А вот вопрос авторам MySQL:

Можно ли ожидать появления конструкции вроде RAISE "my error message" - а-ля postgreSQL?

И еще я уже спрашивал на Веборубе в феврале и получил удовлетворивший меня ответ - но хочется, чтобы другие тоже знали:

Можно ли ожидать появления ключика в mysqldump - который бы позволял дампить базу без информации о том, кому принадлежит объект (в частности, триггеры, речь идет о DEFINER)? Опять же, в pg_dump есть такой ключик - --no-owner
 

Rashkin

Новичок
Автор оригинала: crocodile2u
Подобие mixin можно реализовать с помощью агрегации + перегрузки методов
Нажмите для раскрытия...
товарищь я ведь вроде написал почему не использую функции агрегации.По поводу перегрузки методов,
перегрузка метода это когда имеет место быть.
Код: 
class cls {
  function foo(){

  }

  function foo($a){

  }

  function foo($a, $b){

  }
}
если я конечно не ошибаюсь. такой возможности в php чтото я вообще не наблюдал.

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

crocodile2u

http://vbolshov.org.ru
Rashkin
товарищь, вы могли бы и ощутить разницу между "агрегацией" и "функциями расширения aggregate_*". Сама по себе агрегация в пхп работает стабильно еще с затертой 4-ки.

Да и насчет "foo(), foo($a), foo($a, $b)" - подобный механизм а-ля джава-и-многие-другие - несомненно, обладает рядом достоинств. Однако, попытка его внедрения убила бы начисто другое достоинство пхп: функцию/метод, котороые объявлены как foo() - можно без зазрения совести вызывать как foo(), foo($a), foo($a, $b) - никто слова не скажет.
 

Gorynych

Посетитель PHP-Клуба
с трепетом прочитал написанные вопросы. Какие умные вещи интересуют людей!

если честно, у меня только ДВА банальный вопрос:

1) будет ли что-либо сделано для того, чтобы выпускаемые версии были стабильными?

пример: в версиях 5.2.4 и 5.2.5 при обработке вложенных циклов случются потери текущих значений и полная деинициализация обрабатываемого массива. Я бы предположил срыв стека.

2) можно ли сделать работу функций, ставших уже "стандартными", соответствующей ожиданиям?

пример: можно ли сделать так, чтобы функция strip_tags ДЕЙСТВИТЕЛЬНО занималась тэгами, а не угловыми скобками? Лично для меня результат выполнения нижеследующего кода не очевиден и мало пригоден:
PHP: 
<?php
$str = "1<5";
die(strip_tags($str));
?>
образно говоря: можно ли ожидать стабильности PHP для пользователей или все сводится к красивому, но малополезному "это открытый проект, Вы можете присоединится к его разработке и тестированию и сделать его лучше!"?

P.S. ничего что я не написал что-нибуть умное про ООП или пространство имен?
 
standov

standov

Новичок
Вопрос, возможно наивный: не предполагается-ли в дальнейшем (наверное в далеких версиях) работа php как апликейшн-сервера? поскольку сейчас функционал языка сильно возрос, возросла сложность веб-проектов, многие начинаю смотреть в сторону пайтона именно по обозначенной причине.
 
korchasa

korchasa

LIMB infected
Станут возможны операции в инициализации свойств и констант классов?

PHP: 
class SomeClass
{
    public $cache_dir = PROJECT_DIR . '/var/cache';
    const $cache_url = PROJECT_URL . '/cache';
}
 
standov

standov

Новичок
Автор оригинала: korchasa
Станут возможны операции в инициализации свойств и констант классов?

PHP: 
class SomeClass
{
    public $cache_dir = PROJECT_DIR . '/var/cache';
    const $cache_url = PROJECT_URL . '/cache';
}
Нажмите для раскрытия...
Или хотя-бы констант классов, действительно не хватает порой
 

Rashkin

Новичок
Автор оригинала:
crocodile2u

товарищь, вы могли бы и ощутить разницу между "агрегацией" и "функциями расширения aggregate_*".
Нажмите для раскрытия...
*ржунимагу*

Ну в принципе я бы мог ощутить разницу...

но вобще ссылка на источник бы не помешала
Нажмите для раскрытия...
 

berkut

Новичок
было-бы круто: $db->fetchRow()[0].
и главное, в конце коцов разделить доступ к элементам string от array - {}, []. типы разные, функции разные, а доступ одинаков. ну хоть notice кидать

-~{}~ 17.05.08 00:31:

или strict
 
cDLEON

cDLEON

Онанист РНРСlub
всегда к элементу строки обращался через [] и точно так же буду обращаться - всё таки сишные истоки...
А по поводу $db->fetchRow()[0] - вот этого бы не мешало :)
 
crocodile2u

crocodile2u

http://vbolshov.org.ru
Rashkin
*ржунимагу*
Нажмите для раскрытия...
Экий вы батенька, насмешник...

Ну, стало быть, обратимся к источникам: http://ru2.php.net/manual/en/objaggregation.examples.php ... Что же мы видим?

PHP: 
class Report {
  var $_dt;
  // more properties ...

  function Report() 
  {
      $this->_dt = new MyDateTime();
      // initialization code ...
  }
}
Как видите, пример взят примерно с той же ссылки, что вы привели. Так вот, агрегация - это и есть использование экземпляра одного класса в другом, в виде свойства другого класса. И этот механизм отлично работает, и позволяет в сочетании с перегрузкой методов реализовать подобие множественного наследования. И функции aggregate_* - здесь ни при чем. При желании можно добиться их эффекта, не используя их.

Ну ничего, смотрим дальше... На той же странице:
Aggregation, on the other hand, implies encapsulation (hidding) of the parts of the composition. We can aggregate classes by using a (static) inner class (PHP does not yet support inner classes), in this case the aggregated class definition is not accessible, except through the class that contains it. The aggregation of instances (object aggregation) involves the dynamic creation of subobjects inside an object, in the process, expanding the properties and methods of that object.

Из чего можно заключить, что авторы документации, не полагаясь на знания аудитории в ООП, таки объяснили, что такое агрегация - но некоторые писатели прочитать не удосуживаются.
 
Войдите или зарегистрируйтесь для ответа.
Сверху