Релиз PHP 5.3.0

> Потому, что у явы кошмарно избыточный синтаксис. А иначе вполне могла бы с РНР конкурировать.

И сразу пример аналогичных конструкций в PHP & Java в студию, чтобы мы могли увидеть эту "избыточность".

>Повторюсь, зверские SQL-инъекции у меня народ именно в Java допускал.

гнать таких "программистов"...

>Так в чём разница?

в том, что java приучает/заставляет делать именно так.

>В нормальных языках существуют нормальные dbapi, которые позволяют отделить параметры запроса от его текста. Пыхпых-кодеры вынуждены хардокдить параметры в запрос. (Я уже молчу про вообще отсутствие единого dbapi).

Это вы батенька явно не кодили на php
http://ua2.php.net/pdo

Я знаю шо вы сирано по ссылке не пойдете поэтому копипастну сюда:

$db = new PDO('mysql:host=localhost;dbname=<SOMEDB>', '<USERNAME>', 'PASSWORD');
$stmt = $db->prepare("select contenttype, imagedata from images where id=?");
$stmt->execute(array($_GET['id']));

Все ок с разделением. Никто ниче не вынужден.

>И сразу пример аналогичных конструкций в PHP & Java в студию, чтобы мы могли увидеть эту "избыточность".

Вопрос динамики. На PHP я могу написать так:

class forum_topic extends base_object_db
{
  function main_db() { return 'FORUM'; }
  function main_table() { return 'topics'; }
  function main_table_fields()
  {
    return array(
      'id',
      'make_time' => 'posted',
      'title' => 'subject',
      'message',
      'owner_id',
      'views',
    );
  }
}

И потом сразу использовать так:

$topic = object_load('forum_topic', $_GET['id']);

echo "Title=" . $topic->title();
echo "Date=" . date('r', $topic->make_time());

$topic->set_views($topic->views() + 1, true);

Всё.

На Java придётся для того же самого делать в несколько раз больше
писанины, включая очень рутинную :)

Другое дело, что под Java можно заюзать всякие JRuby/Groovy 
(у кого там можно на ходу произвольно объекты расширять),
но это уже не Java :) Как и PHP - это не Си.

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

Пипец! Сколько же здесь засранцев ... аж дышать невозможно! Обсирают ПХП чуть ли поносом... . Тьфу на вас ... Тьфу на вас ещё раз...

>Когда мне приходилось иметь дело с пыхпыхкодом (как хорошо, что это было давно и не долго), все юзали костыльный mysqli.

Когда мне пришлось иметь дело с PHP, я первым делом (буквально за полчаса в базовом варианте) слепил mysql-драйвер, которым и пользуюсь уже лет... ну, пять, наверное. А, может, и семь. Не вёл я тогда VCS :) И поэтому искренне не понимаю людей, которые в подобных вопросах обвиняют _язык_ :)

> Personal Home Pages.

4.2

PHP is a Hypertext Preprocessor. Из танка, что ли, вылезай.

> Вот что меня раздражает в PHP - это венегрет, остутствие стройнойсти. Пёстрая библиотека и сам языка. Хуже плюсов.

А меня раздражает твой русский язык. По тем же причинам.

> может быть) но имея мало опыта - LAMP (где P - PHP) поднять гораздо проще)

Я долго думал, почему среди маководов так мало пэхэпистов. Попробовал поднять на маке PHP по-человечески, теперь понимаю.

> PHP принадлежит с семейству языков с «автоматической сборкой мусора» или garbage collection. В программировании, сборка мусора (англ. garbage collection, GC) — одна из форм автоматического управления памятью. Специальный код, называемый сборщиком мусора (garbage collector), пытается освободить память, использованную объектами, которые уже не будут востребованы приложением — т.е. производит сборку мусора.

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

>$db = new PDO('mysql:host=localhost;dbname=<SOMEDB>', '<USERNAME>', 'PASSWORD');

нуну, логин-пароль прямо в основном файле...

>но это уже не Java :)

почему это? ;)
вопрос интеграции - один jar-файл...

просто маководы предпочитают руби.. или руби предпочитает маководов :))

впрочем, java-девелоперы маки тоже весьма часто используют

Есть такая штука, называется Hibernate (и она не единственная в своём роде)... Как раз в Java позволяет работать с объектной абстракцией БД.

>почему это? ;)

Потому что это JVM, но не Java :) Java - это конкретный язык.

>вопрос интеграции - один jar-файл...

Обычно не один, а поболее. И к PHP точно также "одной .so-шкой" можно те же PECL-расширения подключать :) Но от этого PHP не становится Си.

>>$db = new PDO('mysql:host=localhost;dbname=<SOMEDB>', '<USERNAME>', 'PASSWORD');

>нуну, логин-пароль прямо в основном файле...

То есть пример уже обязан фигурировать параметрами конфигов?

Хорошо, тогда пример:

$dbh = new driver_mysql(SOMEDB);

Так лучше? :)

>Есть такая штука, называется Hibernate (и она не единственная в своём роде)...

Я знаю. И iBatis. Но, 1) в Гибернейте более громоздкий синтаксис. 2) это только голый ORM, не оперирующий объектами.

> Как раз в Java позволяет работать с объектной абстракцией БД.

Я привёл _полностью рабочий_ пример кода для своего фреймворка. Приведи аналогичный для Гибернейта :)

>голый ORM, не оперирующий объектами

Пиши еще, я прям чувствую, как умнею :D

>Потому что это JVM, но не Java :) Java - это конкретный язык.

jsp - тоже не java? ;)

>Обычно не один, а поболее.

в случае groovy достаточно одного - groovy-all-1.6.3.jar

> Развели истерику как молоденькие девственницы

где?

> В каждом языке есть свои особенности

согласен

> ведь понятно что языка не знаете.

в отличии от вас, знаю.

во-вторых, вы-то сами поняли что написали?

> и сделать нс через :: чревато несовместимостью с 50-60% где используются статические методы

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

а теперь внимание вопрос: каким таким образом смена разделителя "\" на "::" в названии namespace'ов повлияет на вызовы статических функций классов? есть понятие контекста выражения. погуглите. может быть поможет.

> Я вот не понимаю зачем писать ху**ю

да я вот тоже не могу понять зачем вы пишите всё что вам в голову приходит. во избежание сего: когда вам треснет в голову написать что-либо подобное на тему языков программирования, пойдите и почитайте что-нибудь на тему разработки интерпретаторов и компиляторов, очень поможет прояснить многие вопросы хотя бы в теории, на практике, конечно, всё отличается. очень рекомендую: Компиляторы. 2-е издание, авторы: Ахо, Ульман, Лам, Сети.

P.S. мат в сообщение приводит к одной мысли: быдло в комментариях. сделайте одолжение себе и другим - пишите литературным языком.

>голый ORM, не оперирующий объектами.

Чо? o_O

>Чо? o_O

Имеется в виду, что он не создаёт классы и не оперирует произвольно их полями. Только загружает в инициируемые объекты данные.

Я же написал - приведите тут равноценный код для Гибернейта :) Боюсь, он будет раз в 5 длиннее (если не в 10) и с массой повторов. Описание класса в Java-стиле с тонной геттеров/сеттеров, описание БД в XML...

Если не прав - убедите примерами.

> Имеется в виду, что он не создаёт классы и не оперирует произвольно их полями.

Hibernate над классами более зверски изгаляется. Оно вообще-то не только загружает в инициируемые объекты данные, но создает прокси на базе инициируемых объектов.

> Боюсь, он будет раз в 5 длиннее (если не в 10) и с массой повторов.

В пять раз длиннее не будет. Разница, что с Hibernate, что с JPA будет только в геттерах/сеттерах. Метаданные ведь и в аннотациях отлично прописываются.

Сама загрузка объекта - session.get(id) или session.load(id), все остальное - то же самое примерно, но, разумеется, зависит от конкретного web-фреймворка. На EL/JSTL все совсем тривиально.

жава+хибер - примерно на порядок больше кода. большая часть конечно не руками пишется, но кода просто звиздец.
имхо проблема пхп в том, что на нем начинают херню писать, да еще и в связке с mysql. если пхп занимается своим делом - отрисовкой хтмл, то ничего более эффективного не найти. если же из-за убогости mysql начать в пхп бизнес логику тащить, понятно ничего путного на стейтлес, слабо-типизированом языке в плане бизнес логики не написать.
долго рисовали свой проект с логикой в pl/sql и пхп как генератор хтмл. с оракловыми спецами стало грустно, решили раз есть нормальный архитектор для нового клиента воять на жава+хибер+викет. работать - то конечно работает, но томкат со всей логикой в жаве в разы больше памяти требует, хибер генерит такие запросы, что ораклу тяжко, все равно приходится оптимизировать, оказалось когда логика оторвана от субд, интересные нюансы могут вылазить (в плане супорта, типа дба SQL-патч накатил, а девелоперы код не обновили - pl/sql такое не прокатывает - процедуры помечаются инвалидными).
ну и главное - скорость разработки средненького проектитка в десяток человеколет pl/sql+пхп быстрей как-то получается...

> хибер генерит такие запросы, что ораклу тяжко.

Когда у нас такие проблемы были, пользовались нативными запросами. База была с историей лет в двадцать, так что логики в ней более чем хватало. Но логику самого приложения держали в drools - оно и наглядно и быстро.

>В пять раз длиннее не будет.

Я жду равный моему пример :) Если он принципиально не длиннее и не сложнее, то тебе не составит труда его написать тут. Если я на свой потратил с минуту, из которой основное время ушло на форматирование примера пробелами, то неужели тебе будет жалко потратить менее пяти минут на доказательство своей правоты? :)

Форматирование...
Не знаю, что такое принципиальная длиннота, но уж не сложнее точно.

@Entity
@Table(name="topics")
public class ForumTopic implements Serializable {
    @Id @GeneratedValue
    private Integer id;
    @Temporal(TemporalType.TIMESTAMP)
    private Date posted;
    private String subject;
    private String message;
    @ManyToOne
    @JoinColumn(name = "owner_id")
    private Owner owner;
    private Integer views;

    public Integer getId() {return id;}
    public void setId(Integer id) {this.id = id;}
    public String getMessage() {return message;}
    public void setMessage(String message) {this.message = message;}
    public Owner getOwner() {return owner;}
    public void setOwner(Owner owner) {this.owner = owner;}
    public Date getPosted() {return posted;}
    public void setPosted(Date posted) {this.posted = posted;}
    public String getSubject() {return subject;}
    public void setSubject(String subject) {this.subject = subject;}
    public Integer getViews() {return views;}
    public void setViews(Integer views) {this.views = views;}
    public void incView() { this.views = views + 1; }
}

Внутри... ну, пусть сервлета:

TopicForum tf = null;
boolean done = false;
try{
  Integer id = Integer.parseInt(request.getParameter("id");
  tf = SessionUtil.getSession().get(id);
  done = tf != null;
  request.setAttribute("topicForum", tf);
  getServletContext().getRequestDispatcher("/abcd.jsp")
      .forward(request, response);
} catch (Exception e) {
  getServletContext().log(e);
  getServletContext().getRequestDispatcher("/error.jsp")
      .forward(request, response);
} finally{
  if (done && tf != null){
    tf.incView();
  }
}

Вывод:

Title=${tf.title}
Date=<fmt:formatDate dateStyle="both" value="${tf.posted}"/>

>Не знаю, что такое принципиальная длиннота, но уж не сложнее точно.

А описание структуры БД где? Привязка полей объекта к БД?

...

Кому как, а мне мой вариант _приницпиально_ проще :) Сам посмотри незомбированным взглядом мой вариант и твой (предварительно дополни его XML-кой формата БД).

что-то больно много...
у меня процесс апача(2.2.11) с 50 нитями жрет 5 мб. использую php как fast_cgi

соврал. не 50,а 25 тредов... заглянул в конфиг :)

> А описание структуры БД где? Привязка полей объекта к БД?

Аннотации. Явно маркируется только идентификатор записи (@Id). Все остальные поля, не помеченные как transient считаются совпадающими по имени с полем таблицы. Если это не так, используется аннотация @Column, в которой также можно указать дополнительные ограничения, ну и еще что понадобится. Поля-связки описываются соотвествующими аннотациями (например, Owner в этом примере). Связи по умолчанию ленивые, но можно задать их жадными и вытаскивать по разному - все это указывается аннотациями.

> Кому как, а мне мой вариант _приницпиально_ проще :)

Ну, всяк кулик свое болото хвалит, на вкус и цвет все фломастеры разные и так далее. Хотя сам по себе Hibernate - штука в плохом смысле сложная, использовать его более чем просто.

> Сам посмотри незомбированным взглядом мой вариант и твой (предварительно дополни его XML-кой формата БД).

А зачем так грубо? И зачем XML-ка формата БД, если есть аннотации? Все, что не вошло - это xml в пять что ли строк с описанием подключения к базе данных, так подключения и в исходном примере не было.

А еще короче на RoR будет (я на нем для бюжетных клиентов ваяю), и что с того?

>Аннотации.

Хм. А если имя БД/таблицы/поля вычисляемые? :) А если в поле требуется, скажем, UNIX_TIMESTAMP(Date) вставить? :)

'make_time' => 'UNIX_TIMESTAMP(Date)'

Так в аннотациях можно?

>А еще короче на RoR будет

Так кто ж спорит? RoR в этом контексте с той же стороны весов, где и PHP будет ;) Правда, в Вебе его пока всё ещё пренебрежимо мало...

> Хм. А если имя БД/таблицы/поля вычисляемые? :)

ORM так вообще не умеет - никакой. Голый JDBC - сколько угодно. Но оптимизация в этом случае маловероятна. Это не проблема для короткоживущих скриптов, но для более-менее длительного процесса желательно все же пользоваться преимуществами, которые дает бОльшая продолжительность жизни.

> А если в поле требуется, скажем, UNIX_TIMESTAMP(Date) вставить? :)

В аннотациях можно указывать вычисляемые поля (1), можно вешать листенеры на уровне сущности (2) - такие листенеры будут выполнять конвертации туда-сюда.

> Правда, в Вебе его пока всё ещё пренебрежимо мало...

А будет еще меньше.

>ORM так вообще не умеет - никакой.

Мой умеет :) Правда, на практике вычисляемые у меня только БД и таблицы используются.

>> Хм. А если имя БД/таблицы/поля вычисляемые? :)

>ORM так вообще не умеет - никакой

Ошибаешься, мой друк.

А твой ORM дотягивает по своим возможностям до hibernate или там toplink?

Очень может быть. Поделитесь?

>А твой ORM дотягивает по своим возможностям до hibernate или там toplink?

Зачем? Он дотягивает до потребностей, нужных мне лично. Гибернейт - не дотягивает :) Пусть он во многом другом перетягивает, но мне-то оно не нужно.

Ну и славно. Для большиства веб-проектов Hibernate - действительно перебор и неиссякаемый источник геморроя.

>Для большиства веб-проектов Hibernate - действительно перебор и неиссякаемый источник геморроя.

Я когда собирался ORM на Java использовать, смотрел больше в сторону iBatis. Но на практике так и не задействовал.

Теперь же, когда понадобится, скорее всего велосипед буду писать. Заюзаю JBForth2 и буду генерить классы на лету :) В том числе и с вычисляемыми полями.

С iBatis как раз писанины поболе будет, чем у JPA или Hibernate с аннотациями. Проще уж свой слой поверх голого JDBC или спрингового JbdcTemplate набросать... с вычисляемыми полями, если без них уж совсем никуда. Проблема в том, что в джаве для веба запросы-то препаренные обычно используются, и с базами данных, которые их умеют, это повышает несколько повысить быстродействие. Если же имена полей и таблиц в любой момент вычисляются динамически - какие тут препаренные запросы?

>Если же имена полей и таблиц в любой момент вычисляются динамически - какие тут препаренные запросы?

1. Так всё равно с myisam работать. А там транзакций нету :)

2. Почему бы с препаренными запросами и с вычисленными полями не работать?

Да, и классы на лету генерить и на голой джаве проблем никакиx.

> Так всё равно с myisam работать. А там транзакций нету :)

Я все время забываю о существовании MySQL.

> Почему бы с препаренными запросами и с вычисленными полями не работать?

Мммм.... План запроса (а именно он и сохраняется) вообще-то от полей и имен таблиц как-то довольно сильно зависит.

http://www.sqlalchemy.org/docs/05/mappers.html#sql-expressions-as-mapped-attr...

>Да, и классы на лету генерить и на голой джаве проблем никакиx.

Из asm или вручную по-байтово собирать весьма неудобно.

Или там какой-то новый механизм в последние пару-тройку лет появился?

Прямая компиляция классов с текста в Java6 с виду не шибко тороплива...

>>Да, и классы на лету генерить и на голой джаве проблем никакиx.

>Из asm или вручную по-байтово собирать весьма неудобно.

Представляешь, существуют нормальные способы генерить классы в рантайме. Ну практикующим php простительно быть не в курсе.

В пыхпыхе ведь появились (черезжопные) замыкания. Или они только для функций, фабрику классов с их помощью сделать нельзя? ;)

>Представляешь, существуют нормальные способы генерить классы в рантайме.

Ну так имя, сестра, имя :) А то выглядит некрасиво... «У нас есть такие приборы!»

>В пыхпыхе ведь появились (черезжопные) замыкания. Или они только для функций, фабрику классов с их помощью сделать нельзя? ;)

1. Всю жизнь считал, что фабрика классов и генерация кода класса на лету - суть разные вещи :)

2. В PHP классы отродясь можно было через eval определять.

3. При чём тут замыкания? Какое отношение замыкания имеют к генерации классов?

>Ну так имя, сестра, имя :) А то выглядит некрасиво... «У нас есть такие приборы!»

Классы классов, замыкания.

>1. Всю жизнь считал, что фабрика классов и генерация кода класса на лету - суть разные вещи :)

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

>2. В PHP классы отродясь можно было через eval определять.

Это, конечно, делает ему много чести.

>3. При чём тут замыкания? Какое отношение замыкания имеют к генерации классов?

Ты меня этим вопросом поставил в тупик, право слово. Самое прямое, если в двух словах.