30 игровых скриптов, которые можно написать на языке PHP

> К тому строгая типизация - дает и статический контроль типов, программистам жить становится легче...

Есть один хороший пример, на этот счет.

Не помню название паттерна проектирования, но суть очень проста:

1) Есть метод, на вход которому подается всего один параметр (может быть много параметров, один - для простоты пояснения примера).

2) Допустим мы этот параметр методу - типизируем как String. И вызываем этот метод, с данным параметром - из нескольких участков нашего кода.

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

void anyMethod (String param) { if (param == "start") ... else if (param == "stop") ... else if (param == "pause") ... }

- В этом способе передачи параметра данного методу - одно плохо. Малейшая опечатка в коде (который может достигать десятков/стоен тысч строк, постоянно рефакториться и все такое) - и будет ошибка или неправильное поведение кода.

Как это обойти?

Способ прост (название паттерна проектирования лень искать, читал много лет назад).

Можно создать например перечисление (enum) и затипизировать параметр методы - им. Или класс (именно это описано в паттерне). Класс делается абстрактным, от него наследуются производные классы ContentStart, ContentStop и ContentPause. Понятно, что если вы в коде напишите (далее неправильно) CoontentStart, или ошибетесь с регистром одной из букв в названии класса - то интегированная среда разработка (IDE) - вам сразу покажет ошибку.

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

Мамочка.. Зомби.. Некрофилы.. Возвращение мумии...

И заметил ночью, страшно.

> Напиши свои
Может, еще и сайты на си писать? Или свой язык сделать?
Нет смысла, так как есть более совершенные и удобные инструменты для этого. И эти инструменты - не фреймворки для php.

> Читайте доки
Читайте тред, я уже на такие вопросы отвечал.

> И с FastCGI дела обстоят замечательно.
Читайте тред.

> В общем, учим матчасть.
Ну так учите же, теоретик.

> #лять, еще один, не видевший http://php.net/spl, нарисовался.
Как я люблю языковые срачи на ЛОРе - узнаешь столько нового.
В общем, спасибо, если мне придется писать что-либо на пыхапе, обязательно загляну туда.

> Дохлый нонче народ пошел, некомпетентный. Вот раньше был языкосрач, так это был хороший, годный языкосрач. А теперь кинулись обсирать предмет, а предмета-то и не знают — смотрят только, что другие в бложеках понапишут, да копипастят.
Не смотрю, не копипащу. Все из личного опыта.

Если рассматривать "нишевость" PHP, то посмотрите н все с такой стороны:

1) Фактически любой студент ВУЗа может накатать несложный веб-сайт, не такой совсем простой как статичная HTML-страничка. А при сильной упертости (и с юзанием примеров) "силами одного студента" - и сайт с БД.

2) Для освоения ООП - все-таки нужны годы. И практика. И размышления. Какие размышления у студентов первых курсов, кроме как о "телках" и других "земных прелестях".

3) Со временем опытные спецы по PHP стали создавать системы управления контентом, в конце концов отдельным из них это удалось более (такие системы мы знаем), другим менее. Но свою задачу спецы выполнили - на базе языка создали что-то, что позволяет за один вечер развернуть нечто. :)

4) Вспомните те времена, у Java, например. - Провал (поначалу) с AWT (потом создали отличную уже вещь - AWT/Swing, но это было не сразу). Провал с апплетами на Java.

5) Сейчас границы размываются, что-то, немного более сложно, чем "обычно", делается на PHP, а на Java тоже появляются системы управления сайтов в некотором приближении если так сказать - порталы с портлетами к ним.

6) Сколько нужно лет, чтобы сначала освоить J2SE, а потом сколько нужно лет, чтобы перейти на J2EE - ? Студентам такую разработку поручать - навряд ли кто будет.

7) Давайте на забивать золотыми слитками "J2EE" - относительно простенькие гвоздики то (средней сложности сайты). Цены на разработку - тоже существенная, для многих "бизнесов", вещь. И бизнес разный - в виду относительной простоты и дешевизны PHP-разработок - делают и относительно высоконагруженные вещи. Но это - рынок. Если так выгодно, и если технология - намного более массовая, чем J2EE - это всего лишь рынок, и его законы и есть. Нет смысла плеваться, какая ситуация на рынке есть, такая и есть. "Законы жанра", нравится это кому-либо, или не нравится. Никто не плюется, что на данный день не хватает голографический игр (с пивом и бортпроводницами). Ну нет пока таких игр, ну и ладно. Подождем... ;)

> Самая смешная новость за месяц. Особенно код в духе

> $male = array( "William", "Henry", "Filbert", "John", "Pat", );

Там еще парой строк ниже:

$male = explode('\n', file_get_contents('names.female.txt'));

Я, конечно, не изучал PHP, но мои знания английского и логика подсказывают, что что-то в этой строке не так. :)

комментарии опять интереснее читать :)

>> ..список встроенных функций -- тоже условно неисзвестен -- так как он зависит от проинсталлированных дополнений.

> function_exists(), не?

нее.. потомучто на одном компе оно выдасть FALSE, а на другом неисключено что и TRUE... такчто проблему не решает,

список так и остаётся условно неизвестным

непортируемые скрипты/программы -- не нужны.

> $male = explode('\n', file_get_contents('names.female.txt'));

> Я, конечно, не изучал PHP, но мои знания английского и логика подсказывают, что что-то в этой строке не так. :)

ну если только -- после функции "файла достать контентЫ"(file_get_contents) -- ябы приписал функцию trim() :

$male = explode('\n', trim(file_get_contents('names.female.txt')));

а чо ещё тут может настораживать? %) %) %)

>а чо ещё тут может настораживать?

Два момента:

1. male/female.

2. explode(file_get_contents()) вместо file()

:)

>> где там треды и как их использовать в своих программах, а?

> http://ru2.php.net/manual/en/function.pcntl-fork.php не пойдет?

да эт не треды... :-)

...вы чо, товарищщи!? с такимже успехом можно сделать
proc_open("php ... ", ...);
и обмениваться через каналы ввода/вывода

разве это треды... эххх.... *выздыхает*

> 1. male/female.

хы! и ведь правда :-D :-D :-D :-D

(надабыло мне спать ночью)

тут в разговоре чтото промельуивает про типизацию.... посему хочу спросить у специалистов...:

а "утиная типизация" -- это строгая или нет?

вот например код

def func(left, right):
    koef = 37;
    return left*koef + right

в нём left и right это отнюдь не числа (не ограничивается только числами), а объекты интерфейс которых определяет операции(функции) "+" и "*"-на-числовую-константу

если интерфейс объектов не определяет эти операции(функции) то и выполнение кода невозможно

>> Это как раз именно статическая. Вот когда можно писать 2+"2" - это да, это не строгая.. А тот же питон имеет как раз строгую типизацию. Но не статическую.

> В литературе, и в обсуждениях - активно используется следующее название для описанного Вами - "автоприведение типов". :)

Это именно нестрогая типизация. Это общепринятый термин.

Вообще-то, "строгость" типизации - понятие относительное. Например, в Жабе нет неявного приведения строк к числам, но есть неявное приведение целых чисел к числам с плавающей точкой.

> Бывает ли динамическая типизация?

Бывает: сабж, Питон, Руби, ЖабаСкрипт.

> а "утиная типизация" -- это строгая или нет?

Утиная - это динамическая. Это перпендикулярно.

> _обязательной типизации переменных_ (пускай такая формулировка, сейчас не принципиально)

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

> К тому строгая типизация - дает и статический контроль типов, программистам жить становится легче...

Строгая типизация не даёт статической. Питон тому пример.

>но есть неявное приведение целых чисел к числам с плавающей точкой.

В Java есть подводные камни и похуже :)

class test
{
    public static void main (String[] args)
    {
        for(Integer i=120; i<150; i++)
            for(Integer j=120; j<150; j++)
            {
                if(i==j)
                    System.out.println(i);
            }
    }
}

Вывод:

$ javac test.java && java test
120
121
122
123
124
125
126
127

Кто с языком знаком поверхностно - очень долго ошибку искать будет :)

>> К тому строгая типизация - дает и статический контроль типов, программистам жить становится легче...

> Строгая типизация не даёт статической. Питон тому пример.

Я не совсем понимаю Ваши терминов, но если Вы опровергаете Вашим процитированным комментарием - процитированный мой комментарий, то Вы не правы. Процитированный мой комментарий - верен.

Если Вы, по Вашим фразам выше, хотите не использовать термин "автоприведение типов" (возможно мне показалось), то боюсь что Ваши формулировки - имеют ограниченное хождение.

То, что Integer, а не int?

Второй способ исправить ошибку (оба были очевидны сначала, просто первый в данном примере - как самый правильный):

if(i.intValue()==j.intValue())

Ну, да, новички на этом попадаются.

А на чем попадаются середнячки, с рандомным ответом (только не проверяйте в коде, так ответьте):

Integer-переменная, передаваемая в качестве параметра методу - передается по типу или по значению?

>>> К тому строгая типизация - дает и статический контроль типов, программистам жить становится легче...

>> Строгая типизация не даёт статической. Питон тому пример.

> Я не совсем понимаю Ваши терминов

Зато их все остальные программисты понимают.

http://ru.wikipedia.org/wiki/Строгая%20типизация http://ru.wikipedia.org/wiki/Статическая%20типизация http://ru.wikipedia.org/wiki/Динамическая%20типизация

> но если Вы опровергаете Вашим процитированным комментарием - процитированный мой комментарий, то Вы не правы. Процитированный мой комментарий - верен.

Для тугих повторяю: в Питоне типизация строгая и динамическая.

Эти термины не нужны. Есть типизированные переменные, а есть нетипизированные переменные.

> Для тугих повторяю

Доучись в школе, после будешь.

А что не так с этим выводом? Или это _весь_ вывод?

> А что не так с этим выводом? Или это _весь_ вывод?

Трактовка задачи не точна (я по началу даже ее всю и не смотрел, раз нет уточнений и не совсем понятно).

Потом запустил - да, это весь вывод.

> class test

Не только формулировка задачи не точна, но и... название класса пишут с заглавной буквы. :)

Пример нужно доработать, для "промышленного использования"! :)

> Эти термины не нужны. Есть типизированные переменные, а есть нетипизированные переменные.

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

> Доучись в школе, после будешь.

Эй, ты что, обиделся? Просто с тобой нормально общаться невозможно: тебе привожу пример, опровергающий твоё высказывание, а ты говоришь, что моё мнение неверно. Что неверно, Питона не существует?

>То, что Integer, а не int?

Нет, то что Integer неявно кешируется до 127 и поэтому любые Integer(100) равны друг другу через оператор "==", а, например, Integer(200) - уже нет. Как следствие - масса неочевидных ошибок для новичков и неудобство использования для продвинутых пользователей (числа сравниваем по .equals() вместо удобного "==" или извлекаем явно значения)

>но и... название класса пишут с заглавной буквы

Я когда-то формировался как сишнег, а не паскалист ;)

> Просто с тобой нормально общаться невозможно: тебе привожу пример, опровергающий твоё высказывание, а ты говоришь, что моё мнение неверно. Что неверно, Питона не существует?

Я про Питон хоть слово сказал?

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

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

У меня много учебников. Более 200. Правда выучено не так много, как хотелось бы. Будет интересно узнать - где и кто употребляет.

> Нет, то что Integer неявно кешируется до 127 и поэтому любые Integer(100) равны друг другу через оператор "==", а, например, Integer(200) - уже нет. Как следствие - масса неочевидных ошибок для новичков и неудобство использования для продвинутых пользователей (числа сравниваем по .equals() вместо удобного "==" или извлекаем явно значения)

Еу, еу, еу. Я привел 2 ответа, каждый из которых - устраняет проблему в приведенном коде. Что и считается решением проблемы, согласно описанию данной задачи.

> Нет, то что Integer неявно кешируется до 127

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

В учебниках описывают - что Integer является объектной оберткой для int.

С точки зрения эффективности кода - в таких циклах всегда используют простой тип int.

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

При том обилии материала и фреймворков, по моему, - хорошо если человек отлично понимает коллекции, потому что ему их использовать. Понимает еще какие-то вещи. В данном случае - что нужно использовать int, а если сравнивать значения таких переменных, то нужно вызвать соотв. метод.

Внутрення же реализация, в каком месте внутренних классов битовые операции и все такое - гораздо продуктивнее, если человек понимает сам принцип.

Если знать Ассемблер, С++, Java и C#, плюс - огромное количество фреймворков и сторонних технологий, например XML, видов парсеров, CSS и еще кучу других вещей - то, имно, конечно, от человека нельзя ждать знаний тонкостей реализации внутренних классов фреймворков. Как их использовать - о, это да, это он, очень желательно, обязан знать. ВО всяком случае если претендует на соответствующий оклад (потому тчо в жизни трудно найти людей которые все-все-все знают). По моему. :)

Отметим, что в новостях про PHP на ЛОРе самые интересные и насыщенные треды по количеству пузырей в луже.

Половине участвующих ставлю "2". Программист - это призвание. Учиться, учиться и еще раз учиться, как говорил один известный классик.

>С точки зрения эффективности кода - в таких циклах всегда используют простой тип int.

Я же привёл выхолощенный пример :) int далеко не везде применим, увы.

> Я про Питон хоть слово сказал?

Я сказал что ты ошибаешься, и привёл в пример Питон. А ты сказал, что я не прав, и никак это не обосновал. Вот мне и интересно, в чём же я не прав?

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

Смотря что ты понимаешь под программированием. Уж явно не computer science.

> В каких учебниках по программирования Вы их встречали

Последний раз пару дней назад в Real World Haskell.

> Я же привёл выхолощенный пример :)

Вы не читали дней 10 назад - форум на Хабре, там человек, прибежав с собеседования по .NET, поделился выхолощенным примером, ;) который ему задали на собеседовании.

Очень любопытные были мнения. ;)

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

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

Если очень-очень нужно - могу найти тот форум. Но невероятно лениво, если честно. :)

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

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

>>С точки зрения эффективности кода - в таких циклах всегда используют простой тип int.

>Я же привёл выхолощенный пример :) int далеко не везде применим, увы.

Именно. Это же просто PoC. Абстрактнее нужно мыслить. :)

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

Я понял. Надо 2 раза повторять. :)

http://book.realworldhaskell.org/

>там человек, прибежав с собеседования по .NET, поделился выхолощенным примером, ;)

А, нет, у меня это была ошибка в практике, когда первую версию JBForth писал. Уже после начала практического использования выяснилось, что циклы DO работают только до 127. Только с помощью отладчика удалось понять в чём дело :D

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

> Я понял. Надо 2 раза повторять. :)

Просто будь внимательнее в будущем. Чтобы тебе 2 раза не цитировали и твой собеседник зря не тратил на тебя время.

Еще раз, по твой просьбе, повторяю:

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

- Здесь очень хорошо видна формулировка вопроса:

1) Название книги. 2) Автор книги. 3) "если можно - не считать существенным... если автор книги... привел на одной из первых страниц учебника - единственное упоминание этой фразы".

Ты привел ответ только по п.1

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

Но так и невыясненным остался п.3

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

Как на счет п.3 - ? Долгно еще ждать ответа?

> Уже после начала практического использования выяснилось, что циклы DO работают только до 127. Только с помощью отладчика удалось понять в чём дело :D

У меня этот пример, в каком-то плане - выплыл в J2EE. Уже и забыл, что Integer так нельзя сравнивать (при больших нагрузках и не такое забудешь, хотя бы временно). Код написал, проверил. Код проверку не прошел. Причину нашел быстро. Вот и вся story. :)

Еще обращаю твое внимание, на эту же фразу:

> В каких учебниках по программирования Вы

УЧЕБНИКАХ.

А ты привел только один. До вечера сидеть будем? Если ты затрудняешься на данный момент обстоятельно ответить, так и скажи.

Потом посмотрю, что ты найдешь, уточнишь ли на счет "единственного упоминания на одной из первых страниц" - по КАЖДОЙ такой книге.

Просто реально какая-та редкая штука. Поэтому и такая постановка вопроса.

Переубедишь, ЕСЛИ - признаю твою правоту. В конце концов может я невнимательно читаю, мало ли. :)

При статической типизации типы переменных определяются во время компиляции, при динамичесой --- в runtime.

При строгой типизации любое операция принимает только те операнды, для типов которых она определена, т.е. неявного приведения типов нет (как уже сказали выше, это понятие несколько относительное --- в большинстве ЯП целые приводятся к вещественным при необходимости, но они считаются строгими: это почти не опасно, в отличие от 1+"2" == 3).

Неужели это так сложно?

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

> http://book.realworldhaskell.org/

Большое спасибо, давно хотел её почитать и даже не подозревал, что эта книга есть в онлайне.

> Ты привел ответ только по п.1

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

Я подразумеваю, что собеседники умеют пользоваться Гуглом.

> Как на счет п.3 - ? Долгно еще ждать ответа?

Если так интересует, то там половина второй главы посвящена типизации вообще и в Хаскелле в частности.

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

Неправда. Только некоторые. :)

Я вот тоже просил обстоятельно объяснить, в чём я не прав? Вот тот пост, где это утверждалось: http://www.linux.org.ru/jump-message.jsp?msgid=3953708&cid=3956105

> При статической типизации типы переменных определяются во время компиляции, при динамичесой --- в runtime.

Хорошо. Согласно этой фразе, вот берем ЯП Java и пишем следующий код:

int a = 5; AnyClass b = new AnyClass ();

Согласно Вашему утверждению из первой фразы - переменная a относится к статической типизации, а переменная - к динамической (при условии что к переменной b применяем полиформизм).

Это неверно.

> Неужели это так сложно?

Нужели сложно не путаться в формулировках, добиться их непротиворечивости?

> При строгой типизации любое операция принимает только те операнды, для типов которых она определена, т.е. неявного приведения типов нет (как уже сказали выше, это понятие несколько относительное --- в большинстве ЯП целые приводятся к вещественным при необходимости, но они считаются строгими: это почти не опасно, в отличие от 1+"2" == 3).

Есть устоявшийся термин - "автоприведение типов". При желании его можно найти как миниумум в 10 учебниках по программированию.

Что тут за намеки "это понятие несколько относительное" - ? Ничего относительно конкретно в АВТОПРИВЕДЕНИИ ТИПОВ - нет!

Все конкретно описано в широко применяется во многих ЯП.

От лукавого какие-то путанные, противоречивые формуливроки.

:)

И на тему.

Всё-таки не нравится мне PHP, после Python + Django. Но вот что хорошо, так это тонны всякой всячины, уже написанной и готовой к употреблению.

Кстати, давно хотел узнать: как соотносится производительность PHP с Python на реальных задачах (в веб-области, конечно)?

>> http://book.realworldhaskell.org/

> Большое спасибо, давно хотел её почитать и даже не подозревал, что эта книга есть в онлайне.

Одна из самых толковых из тех, что я встречал.

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

> Хорошо. Согласно этой фразе, вот берем ЯП Java и пишем следующий код:

> int a = 5; AnyClass b = new AnyClass ();

> Согласно Вашему утверждению из первой фразы - переменная a относится к статической типизации, а переменная - к динамической (при условии что к переменной b применяем полиформизм).

> Это неверно.

a создаётся в стеке и имеет тип int. b создается в куче и имеет тип AnyClass. Обе переменные имеют статическую типизацию. Полиморфизм ортогонален этому.

> Есть устоявшийся термин - "автоприведение типов". При желании его можно найти как миниумум в 10 учебниках по программированию.

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

> Я вот тоже просил обстоятельно объяснить, в чём я не прав? Вот тот пост, где это утверждалось: http://www.linux.org.ru/jump-message.jsp?msgid=3953708&cid=3956105

Давайте определимся в терминах, из-за путаницы во фразах - мой ответ к Вам на ВАШ ЭТОТ ВОПРОС - упрется СНОВА В СПОРНЫЕ МОМЕНТЫ В ФОРМУЛИРОВКАХ.

Ну разве это не очевидно?

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

> Неправда. Только некоторые. :)

См. выше, в этом посте.

> Я подразумеваю, что собеседники умеют пользоваться Гуглом.

Не сползай с конкретно заданного тебе вопроса. Где книги, где широкие упоминания этих путанных, противоречивых формулировок?

> Если так интересует, то там половина второй главы посвящена типизации вообще и в Хаскелле в частности.

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

Небось в Википедию запостил сам автор данной книги, нет? ;) :D