1. Я тоже. И признаю многие недостатки PHP и достоинства Java. Как и наоборот. А вообще мне Питон нравится больше их обоих.
2. А я хочу читать. Как топики, так и комментарии к ним. И хочу, чтобы они было конструктивными.
3. Не вижу
1. Это и на PHP реализуемо. Другое дело, что это не всегда лучшее решение.
2. Опять про независимость от базы данных? Что под этим подразумевается? То что PHP-шнику придется при переходе с mysql на PG заменять вызовы mysql_* на
pg_*? Но никто вменяемый напрямую к ним не обращается.
Или под этим подразумевается, что имея сервер mysql3 можно использовать триггеры, хранимые процедуры и связывание по ключам?
3. Опять модное слово. Что под ним подразумевается такого, что принципиально не достижимо на PHP?
4. Ну и что?
5. А с вагонами библиотек для PHP вы не знакомы?
6. У PHP тоже все это есть. В несколько более меньших объемах, но это не критичный пункт.
7. Ой, да хватит, про эту безопастность. Человек, который понимает, что он делает, пишет безопастно и на PHP. Который не понимает, тот пишет с дырами на всем
чем угодно.
8. Вот. Определенные проблемы. У PHP одна проблема - web. А у java куча. И в большинстве из них пых яве, несомненно, никакой не соперник. Надо все-таки
понимать, что есть различные проблемные области и нет универсального решения.
В html код включаютя только идентификаторы, больше ничего. Вся логика выполняется в классах, которые наследуются от абстрактной
страницы.
Если вы про возможность вставлять php-код в html, то наличие этой (очень удобной во многих случаях возможности) никоем образом не мешает обходиться без нее и
строить логику как угодно.
Наличие различных валидаторов полей форм (как встроенных, так и пользовательских).
Подобные решения (как и в ASP) позволяют быстро сварганить шаблонную систему. Но не дают программисту более-менее глубокого контроля над процессами и, что
Ну не надоело еще людям приходит в темы о языках на которых они не пишут и кричать, что это все гауно, а вот языки которые они знают, это рулез?
Читать во всяком случае надоело.
Насчет двух кусков кода - они одинаковые. Неотформатированное, неоткомментированное мясо на два экрана, разбираться в котором нет никакой охоты.
Пояснили бы на конкретных небольших примерах было бы другое дело. А так, просто очередной трёп.
А PHP не просто интерпретатор, а транслирующий. Java и C#, кстати, в некотором смысле тоже. Однако, различие интерпретатор/компилятор влияет только на скорость исполнения, но никак не на дырявость, типизированность и тому подобное.
Скрипт, же переводится, как сценарий. Скрипты выполняются в других системах, манипулируя уже существующими объектами. Браузерный Javascript - скриптовый язык, а PHP никакой не скриптовый.
Очередной холивар? Давайте.
Откуда это нормальные языки двигались к строгим типам? От нетипизированных ассемблеров?
Вам не кажется, что изначально строгие типы, это ограничение компилирующих языков?
Что значит "не делающий существенного различия между кодом и данными"? Вы знакомы с функциональным программированием и т.п? PHP по "неделанью различий" очень далеко до многих языков. Хотя вы можете считать их всех ненормальными.
Поэтому любой php скрипт по дефолту остается дырявым, пока не доказано обратное
Хватит выдвигать безумные лозунги, их тьма. Мотивируйте.
Кстати, что вы подразумеваете под "скриптовыми" языками?
Слишком сумбурно и непоследовательно.
Пишется "не делайте так", "потенциальная опастность", а объяснений "почему" нет.
В пятой версии появилась константа E_STRICT, показывающая строгие замечания по поводу кода. Разумеется, их желательно видеть, но они не входят в E_ALL, потому будем использовать числовое значение error_reporting(8191)
Только что константы были, теперь какое-то непонятное число. Почему не error_reporting(E_ALL | E_STRICT)?
В общем плане верно, но если вдаваться в подробности, то как вы прокомментируете это: var proto1 = {x: 1};
var proto2 = {x: 2};
function constr() {}
constr.prototype = proto1;
var obj = new constr();
alert(obj.x); // 1
constr.proto = proto2;
// либо obj.constructor.prototype = proto2;
alert(obj.x); // 1
Прототипная парадигма больше подходит к одному, классовая к другому.
Для работы в браузерах больше подходит прототипная.
ECMA 4 же разрабатывается уже не столько для браузеров, сколько для более широкого круга задач.
у нас есть замечательное предложение this (или как поправили выше with)
Оно далеко не такое замечательное. Применять его не рекомендуют уже даже разработчики JS.
with не позволяет нормально оптимизировать код и может иметь нежелательные эффекты, когда использующий не совсем четко представляет, как разрешается область видимости.
Просто, смотря кого считать разработчиками. Если каждого вебмастера, который пытается добавить на свою страницу какой-то эффект, то да, их тьма и им понимать ничего не нужно. Но они и без классов прекрасно обходятся.
Настоящие разработчики, все-таки, начинают постепенно появляться в должных количествах.
Если вы про эмуляцию классов, то, имхо, мотоцикл, это как раз прототипы. Только, конечно, с велосипеда на мотоцикл так просто не пересесть, придется долго тренироваться. А эмуляция классов, это вообще даже не велосипед, а самые что ни на есть костыли.
2. А я хочу читать. Как топики, так и комментарии к ним. И хочу, чтобы они было конструктивными.
3. Не вижу
1. Это и на PHP реализуемо. Другое дело, что это не всегда лучшее решение.
2. Опять про независимость от базы данных? Что под этим подразумевается? То что PHP-шнику придется при переходе с mysql на PG заменять вызовы mysql_* на
pg_*? Но никто вменяемый напрямую к ним не обращается.
Или под этим подразумевается, что имея сервер mysql3 можно использовать триггеры, хранимые процедуры и связывание по ключам?
3. Опять модное слово. Что под ним подразумевается такого, что принципиально не достижимо на PHP?
4. Ну и что?
5. А с вагонами библиотек для PHP вы не знакомы?
6. У PHP тоже все это есть. В несколько более меньших объемах, но это не критичный пункт.
7. Ой, да хватит, про эту безопастность. Человек, который понимает, что он делает, пишет безопастно и на PHP. Который не понимает, тот пишет с дырами на всем
чем угодно.
8. Вот. Определенные проблемы. У PHP одна проблема - web. А у java куча. И в большинстве из них пых яве, несомненно, никакой не соперник. Надо все-таки
понимать, что есть различные проблемные области и нет универсального решения.
Если вы про возможность вставлять php-код в html, то наличие этой (очень удобной во многих случаях возможности) никоем образом не мешает обходиться без нее и
строить логику как угодно.
Подобные решения (как и в ASP) позволяют быстро сварганить шаблонную систему. Но не дают программисту более-менее глубокого контроля над процессами и, что
важно, понимания этих процессов.
И вообще спор пошел не о языках, а о библиотеках.
Читать во всяком случае надоело.
Насчет двух кусков кода - они одинаковые. Неотформатированное, неоткомментированное мясо на два экрана, разбираться в котором нет никакой охоты.
Пояснили бы на конкретных небольших примерах было бы другое дело. А так, просто очередной трёп.
Универсальный скриптовый язык, согласен :)
Скрипт, же переводится, как сценарий. Скрипты выполняются в других системах, манипулируя уже существующими объектами. Браузерный Javascript - скриптовый язык, а PHP никакой не скриптовый.
if (!defined("E_STRICT")) define("E_STRICT", 2048);кавычки не забываем :)
Откуда это нормальные языки двигались к строгим типам? От нетипизированных ассемблеров?
Вам не кажется, что изначально строгие типы, это ограничение компилирующих языков?
Что значит "не делающий существенного различия между кодом и данными"? Вы знакомы с функциональным программированием и т.п? PHP по "неделанью различий" очень далеко до многих языков. Хотя вы можете считать их всех ненормальными.
Хватит выдвигать безумные лозунги, их тьма. Мотивируйте.
Кстати, что вы подразумеваете под "скриптовыми" языками?
Пишется "не делайте так", "потенциальная опастность", а объяснений "почему" нет.
Только что константы были, теперь какое-то непонятное число. Почему не
error_reporting(E_ALL | E_STRICT)?Вообще-то, там по одной персоне на пирамиду. Одному Хеопсу слишком жирно было бы.
var proto1 = {x: 1};var proto2 = {x: 2};
function constr() {}
constr.prototype = proto1;
var obj = new constr();
alert(obj.x); // 1
constr.proto = proto2;
// либо obj.constructor.prototype = proto2;
alert(obj.x); // 1
Для работы в браузерах больше подходит прототипная.
ECMA 4 же разрабатывается уже не столько для браузеров, сколько для более широкого круга задач.
arguments.callee.prototype = { ... }:)
Оно далеко не такое замечательное. Применять его не рекомендуют уже даже разработчики JS.
with не позволяет нормально оптимизировать код и может иметь нежелательные эффекты, когда использующий не совсем четко представляет, как разрешается область видимости.
Настоящие разработчики, все-таки, начинают постепенно появляться в должных количествах.