Зачем пишут ./ в начале файла?

require_once "./file.php";

include("./file.php");

Дело в том, что если в директиве include_path файла php.ini есть . точка –

; Unix include_path
include_path=".:/php/includes"

; Windows include_path
include_path=".;c:\php\includes"

это разрешит относительные инклюды, т.к. . означает текущую директорию (dirname(__FILE__), кот. может не совпадать с рабочей директорией – из кот. вызван основной скрипт - getcwd()). Это полезно для файлов библиотек, зависимых друг от друга и лежащих в одной папке.

Тем не менее, если нужный для инклюда файл находится относительно рабочей директории – рекомендуется явно указывать "./file.php", чтобы PHP не проверял каждый раз текущую директорию скрипта, вызывающего include(). (Конечно, если сам скрипт c инклюдом никто не инклюдит, то разницы не будет).

Из твиттера (#): Если имя файла начинается с ../ – PHP не использует include_path, не ищет относительно директории php-файла с этой строчкой, а только относительно work dir (т.е. того файла, кот. был запущен). Чтобы инклюдить относительно конкретного скрипта:

require_once dirname(__FILE__)."/../file.php";

0.1 1.0

Никогда не понимал зачем какой-либо разработке ставить версию меньше единицы.

Версия 0.1 Что-то вроде pre-alpha версии (полуночные релизы). Т.е. когда ещё не реализована вся функциональность продукта, или разработчик ещё только определяет какие возможность должна иметь программа. И кажется логичным не выпускать программу под первой версией. А выпустить версию номер ноль. Чтобы в будущем, наконец дойти до версии с полной фунциональностью – 1.0

Чтобы:

• публично выкладывать, вместо того, чтобы сразу завершить начатое (желание одобения)
• избежать негативных отзвов (бету будут ругать, хотя и понимают) (избежать боли)
• всё превращается в нескончаемую гонку за идеалом, появляются версии 0.99 , 0.21a , 0.21b+4 (ноль 21 b плюс 4).

Например, Wireshark, отличный сниффер. Но я не заметил особых отличий версий 0.8, 0.99 и 1.4.4 (потому что не использовал полную функциональность, неверно). При этом, например, версия 1.4.2 была жутко тормознутая, а уже 1.4.4 - просто воплощение скорости, учитывая java.

Есть и совсем позорные примеры: deskdo.yandex-nano.ru (не пользуюсь, просто для примера) – ну что это такое: β1.4 - бета 1.4, ужос (я бы понял 1.4beta).

Тем не менее.

Я всегда стараюсь ставить на новых разработках версию 1.0.0, даже без приставки beta.

Но я допускаю, что, если необходимая и достаточная функциональность не закончена, а данный модуль/класс уже надо использовать в другом коде, можно поставить версию <1 (в зависимости от стадии готовности 0.1-0.9). А, как только минимальная, базовая, необходимая и достаточная функциональность будет достигнута, пусть это даже был этап версии 0.7.0) – сразу поставить версию 1.0.0, и продолжать добавлять уже новые, дополнительные возможности в разработку.

И немного о major.minor[.maintenance] ^(1.0.0)

Я не собираюсь читать (сам) статью из википедии.

Скажу, что последняя цифра в версии (maintenance) определяет любые мелкие изменения, как правило соответствует одной строке в ChangeLog.txt. Средняя определяет более-менее значительные изменения функциональности (допустимо 1.9.0, 1.10.0, 1.11.0, т.к. это не стадия готовности major). Ну и первая (major) – кардинальные изменения (имеются в виду, конечно, не изменения совместимости, а новые возможности).

Меня интересовал вопрос: стоит ли создавать "полностью статические классы"? (На самом деле такого определения не существует). Я говорю про классы, где не обязательно создавать объект для использования его возможностей. Все свойства и методы имеют аттрибут static и вызываются как: ClassA::Method1(); ClassA::$prop1;.

Я пытался не использовать слово class и писать методы и свойства, как функции и глобальные переменные с префиксом модуля: PrefixA__Method1(); $PrefixA__prop1.

Теперь нашёл цитату из Вики:

Существующие парадигмы программирования, такие как процедурное, модульное и объектно-ориентированное программирование (ООП), предоставляют определённые способы для разделения и выделения функциональности: (функции, классы, модули). #

И определение декомпозиции:

Декомпозиция — научный метод, использующий структуру задачи и позволяющий заменить решение одной большой задачи решением серии меньших задач. #далее см. вики

То есть, когда речь идёт о создании нового уровня абстракции, на самом деле нет ничего криминального в том, чтобы создать одну новую функцию, или расположить группу функций с префиксами в отдельном файле, или даже добавить к этой группе функций глобальную переменную с префиксом, которую будут использовать все эти функции. Пока может существовать только один экземпляр класса (синглтон или статический класс) - всё определяется лишь 1. Возможностями языка программирования (поддерживает ли классы), 2. Стилем программиста (если он привык использовать сторонние классы, лучше объединять группы функций одной задачи в классы).

Отступление: Кстати в СИ вы можете поставить перед именем функции (я не про методы) static, таким образом, ограничив её область видимости одним модулем (т.е. файлом). Своего рода private method.

Тем не менее, даже статические классы могут дать ряд преимуществ:

1. В PHP, размещённый в отдельном файле класс даёт гораздо больше спокойствия, чем группа функций, т.к. вы пишите весь код внутри методов. В случае с функциями вы не можете быть уверены, что в самом файле кроме объявления глобальных переменных нет никакого кода (что нарушило бы всю идею модулей/абстракции/группы_функций). p.s: В СИ таких проблем нет.
2. Возможность расширения существующей функциональности без использования коллбэков (с помощью наследования):

   Вместо:

   function do1() {
       global $modA__before_do1, $modA__after_do1;
       // вызов ф-ции с именем, установленным в глобальной $modA__before_do1:
       if (function_exists($modA__before_do1)) $modA__before_do1();
       /* -- основная функциональность do1() -- */
       if (function_exists($modA__after_do1)) $modA__after_do1();
   }

   Пишем:

   class modAplus extends modA {
       function do1() {
           /* -- делаем то, что пришлось бы выписывать в ф-цию и устанавливать её имя в $modA__before_do1 -- */
           parent::do1();
           /* -- делаем то, что пришлось бы выписывать в ф-цию и устанавливать её имя в $modA__after_do1 -- */
   }

3. И, конечно, главное, (ради чего может послужить и предыдущий пункт) – это полиморфизм. (Благо в PHP его можно использовать и со статическими классами).
   Для одной и той же задачи мы можем выбрать подходящий по обстоятельствам способ решения. Например поддержка сохранения данных в файлах 2-х разных форматов:

   class CVS {
       function getData($fname) { /*...*/ return $res_array;}
       function putData($fname, $array) { /*...*/ }
   }
   class XML {
       function getData($fname) { /*...*/ return $res_array;}
       function putData($fname, $array) { /*...*/ }
   }

   Мы не знаем о внутреннем устройстве классов (инкапсуляция), но главное, что теперь нам ещё и не нужно знать имена методов для работы с файлами каждого типа:

   $STORAGE = "CVS"; // напр. из конфига, можем спокойно заменить на "XML" не переписывая код ниже
   $STORAGE::getData(); // начиная с PHP 5.3.0
   $STORAGE::putData();

   p.s: Конечно в PHP можно использовать и трюк с include($CONFIG_FILETYPE."_funcs.php"); файлов с одинаковыми именами функций. Но это резко снизит возможности использования.

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

Однако, принцип работы собаки, @ - оператора подавления ошибки прост: до вызова функции/переменной/константы ^{(всего что может возвратить значение)} error_reporting() устанавливается в ноль. А в конце вызова возвращает своё значение.

А это означает, например @ перед именем пользовательской функции полностью подавит все сообщения об ошибках, произошедших в ней, независимо сколько их было (неопределённые переменные и константы, неверные аргументы встроенных функций и вызовы несуществующих функций/методов). Вы не увидите этих ошибок ни браузере, ни даже в логе! И будете долго думать, что же не так.
А в случае с @include("file.php"); это будет означать подавление всех ошибок в этом файле!

Что же делать? Можно писать так:

file_exists("f.php") and include("f.php");

Да, отвратный метод из-за необходимости следить за 2 строками с именем файла.

Тогда лучше в начале каждого файла, инклюживаемого через @include() сбрасывать error_reporting:

error_reporting(get_cfg_var('error_reporting'));  // for @include(), may just E_ALL

Тема для многих, наверное, боян. Но в свете скорого ввода зоны .рф хочу сказать что это недопустимо ставить в один ряд официально зарегистрированную ICANN зону и пустышки, словосочетания, которые будут работать только в специальном браузере (плагине, подробнее). Гугл Хром, Опера уже перешли на омнибокс, теперь русское словосочетание, набранное в адресной строке будет открывать страницу поиска, где юзеры будут тыкать по соответствующему линку. Зачем нужны русские имена? Но ещё важнее, зачем портить себе репутацию таким глупым уже неактуальным способом.

Тут случайно встретил использование тэга acronym для расшифровки сокращения. Например так: a/k/a

Обычно я в таких случаях просто ставлю ссылку на wiki, или в поиске нахожу релевантную страничку с описанием термина/сокращения. За что (много ссылок), как я полагаю, поисковики жутко пессимизируют этот блог. (Зачем после этого уважать их алгоритмы ссылочного ранжирования, – это аргумент противникам продажных ссылок.)
И хотя этот тег не преднаначен для подсказок кроме как аббревиатур, почему бы не попробовать его так использовать.

С HTML 5 совместим только тэг abbr. В описании сказано: Кроме того, поисковые системы индексируют полнотекстовый вариант сокращения, что может использоваться для повышения рейтинга документа.
Не уверен что это правда. Но почему бы не попробовать, если будут резульаты - узнаем.

Далее »

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

 + R, cmd

— открываю консоль и —

c:\php5\php -r "echo 'hellow world!';"

Как это возможно? Всё просто. Выполнить php-код, указанный в кавычках позволяет ключ -r CLI-версии PHP.
Для PHP 4 – это c:\php4\cli\php -r "phpinfo();"

UPDATE: Для удобства можно назначить горячую клавишу, напр. Ctrl+Alt+P AutoHotKey'ем:

#IfWinActive ahk_class ConsoleWindowClass
  !F4::Send, exit{RETURN}   ; выход из cmd.exe по Alt+F4
  !p::SendInput c:\php5\php -r ""{LEFT}   ; Подстановка для cli-версии PHP5 по Alt+p
  ^p::SendInput c:\php\cli\php -r ""{LEFT}   ; Подстановка для cli-версии PHP4 по Ctrl+p
#IfWinActive