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

Что нового в PHP 5.3?

By Ben Balbo

PHP шестой версии уже не за горами, но для нетерпеливых разработчиков, есть хорошая новость — много возможностей, которые планировались в PHP 6, были портированы в PHP 5.3, финальный релиз которого планируется в первой половине этого года (прим. переводчика: не так то оно случилось, только вот недавно вышел ).

Эта новость, возможно, также будет хорошо воспринята теми, кто хотел бы воспользоваться новыми возможностями, но хостинг-провайдеры некоторое время не будут обновлять PHP до версии 6 — хостинг-провайдеры обычно оттягивают серьезные обновления версий программ пока выполняется их тестирование ( читать как: пока стабильность сначала не будет проверена где-нибудь в другом месте). Множество хостеров, возможно, отсрочат обновление своих услуг до версии 6.1. А маленькие обновления с 5.2.x до 5.3, возможно, будут маленьким препятствием для большинства хостинг компаний.

Эта статья показывает новые возможности , приводит примеры их возможного использования и предусматривает демонстрационный код чтобы вы поняли и работали с минимум суеты. Здесь не описывается как установить PHP 5.3 — последний возможный релиз [2] для разработчиков . Если вам хочется попробовать код с этой статьи, вы должны установить PHP 5.3, когда скачаете архив исходных кодов [3]. Статью о установке PHP 5.3 [4] вы можете найти на сайте Melbourne PHP Users Group.

Пространства имён

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

В объектно-ориентированном мире столкновение имён попадается редко. Рассмотрим следующий пример кода, который базируется в фиктивном движке для блогинга:

<?php
class User {
  public function set( $attribute, $value ) {
    ...
  }
  public function save() {
    ...
  }
}

$user = new User();
$user->set('fullname', 'Ben Balbo');
$user->save();

В примере, метод save() не совпадает ни с одним другим методом , так как находится в классе User. Всё же есть потенциальная проблема: класс User может быть уже определён в какой-то другой части системы, если, например, приложение запускается вместе с системой управления контентом ( content management system — CMS ).

Решением этой проблемы — использовать новый оператор namespaces. Исходя с вышеописанного кода, обратимся к следующему примеру:

<?php
namespace MyCompany::Blog;

class User {

       public function set( $attribute, $value ) {
               $this->$attribute = $value;
       }

       public function save() {
               echo '<p>Blog user ' . $this->fullname . ' saved</p>';
       }

}

<?php
$user = new MyCompany::Blog::User();
$user->set('fullname', 'Ben Balbo');
$user->save();

На первый взгляд, преимущество предложенного пространства для наших функций могуть быть не очевидны — прежде всего мы просто изменили MyCompany_Blog_User на MyCompany::Blog::User. Тем не мение, мы можем сейчас создать класс User для CMS [5], используя другое пространство имён:

<?php
namespace MyCompany::CMS;

class User {

       public function set( $attribute, $value ) {
               $this->$attribute = $value;
       }

       public function save() {
               echo '<p>CMS user ' . $this->fullname . ' saved</p>';
       }

}

Теперь мы можем использовать классы MyCompany::Blog::User и MyCompany::CMS::User.

Ключевое слово use

Адресация классов, используя полные имена, по прежнему длинная, и если вы используете много классов с пространства имён MyCompany::Blog, вы не хотели бы набирать этот путь к классу каждый раз. Тогда ключевое слово use вам в руки. Ваше приложение, скорое всего, будет использовать различные классы в любой момент времени. Предположим, пользователь создаёт новую запись:

<?php
use MyCompany::Blog;
$user = new Blog::User();
$post = new Blog::Post();
$post->setUser( $user );
$post->setTitle( $title );
$post->setBody( $body );
$post->save();

Слово use не ограничивается определением пространства имён в текущем действии. Вы также можете использовать его для импортирования одного класса в ваш файл, как ниже:

<?php
use MyCompany::Blog::User;
$user = new User();

Алиасы пространства имён

Ранее, я говорил, что одним из преимуществ namespacing, является возможность определения более чем на одного класса с таким же именем в разных пространствах имен. Несомненно, будут случаи, когда эти два класса используют один и тот же скрипт. Мы могли бы импортировать пространства имён, однако, у нас есть возможность импортировать просто эти классы. Чтобы сделать это, мы можем использовать псевдонимы для пространства имён, например, так:

<?php
use MyCompany::Blog::User as BlogUser;
use MyCompany::CMS::User as CMSUser;

$bloguser = new BlogUser();
$bloguser->set('fullname', 'John Doe');
$bloguser->save();

$cmsuser = new CMSUser();
$cmsuser->set('fullname', 'John Doe');
$cmsuser->save();

Констанкты классов

Константы теперь возможно определить на уровне классов! Имейте ввиду, что константы классов доступны, когда вы импортируете пространства имён, но вы не можете импортировать константу в себя. Вот пример того, как вы могли бы использовать их:

<?php
namespace MyCompany;

class Blog {
       const VERSION = '1.0.0';
}

<?php
echo '<p>Blog bersion ' . MyCompany::Blog::VERSION . '</p>';

use MyCompany::Blog;
echo '<p>Blog version ' . Blog::VERSION . '</p>';

use MyCompany::Blog::VERSION as Foo;
echo '<p>Blog version ' . Foo . '</p>';

Вывод:

Blog bersion 1.0.0
Blog version 1.0.0
Blog version Foo

Функции в пространстве имён

Использование статических методов класса протестует против использования функций в объектно-ориентированном мире, в котором мы живём. Тем не менее, коль вам нужно добавить функцию в ваш пакет, это тоже по силам пространству имён ( namespacing )!

Вот пример

<?php
namespace bundle;
function foo() { echo '<p>This is the bundled foo</p>'; }
foo(); // Это выведет 'This is the bundled foo'

<?php
function foo() { echo '<p>This is the global foo</p>'; }
require( 'lib/bundle.class.php');
bundle::foo(); // Это выведет 'This is the bundled foo'
foo(); // Вывод: 'This is the global foo'

Глобальное пространство имён

Глобальное пространство имён — это важное возмещение, когда вы в ладах с функциями. В предыдущем примере, Вы заметите, что нет прямого пути вызова глобальной функции foo с основного кода (function from within the bundle code).

Метод для решения вызовов функций — это использовать текущее пространство имён (The default method of resolving calls to functions is to use the current namespace). Если функцию нельзя найти, то она будет искать найдена, то будут рассматриваться внутренние функции по имени. Автоматически будут искаться функции в других пространствах имён.

Для вызова глобальной функции foo с внутреннего связующего пространства имён, нам следует указать глобальное пространство имён напрямую. Делается это с помощью двоеточия:

<?php
namespace bundle;
function foo() { echo '<p>This is the bundled foo</p>'; }
foo(); // This prints 'This is the bundled foo'
::foo(); // This prints 'This is the global foo'

Автозагрузка классов в пространстве

Если вы описали магическую функцию _autoload для подключения файлов с описанием классов при запросе, тогда вы, возможно, используете каталог, с которого подключаются все ваши файлы с классами. До использования пространств имён, этого было бы достаточно, так как каждый класс имеет уникальное имя. Теперь, можно иметь много классов с одним именем.

К счастью, функция _autoload будет получать полную ссылку на класс в пространстве имён. Значит, вы могли бы получать такой вызов:

__autoload( 'MyCompany::Blog::User' );

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

function __autoload( $classname ) {
       $classname = strtolower( $classname );
       $classname = str_replace( '::', DIRECTORY_SEPARATOR, $classname );
       require_once( dirname( __FILE__ ) . '/' . $classname . '.class.php' );
}

Результатом будет подключение файла./classes/mycompany/blog/user.class.php.

Позднее статическое связывание

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

<?php

class ParentClass {

       static public function say( $str ) {
               self::do_print( $str );
       }

       static public function do_print( $str ) {
               echo "<p>Parent says $str</p>";
       }

}

class ChildClass extends ParentClass {

       static public function do_print( $str ) {
               echo "<p>Child says $str</p>";
       }

}

ChildClass::say( 'Hello' );

Вы возможно ожидаете, что скрипт вернёт “Child says Hello”. Хотя я понимаю, почему вы могли бы так подумать, но вы будете разочарованы, когда уведите “Parent says Hello”.

Причина этого в том, что ссылки self:: и _CLASS_ принимают решение в классе, в котором эта конструкция используется. В PHP 5.3 теперь есть конструкция static::, которая решает какой класс вызван во время выполнения программы:

        static public function say( $str ) {
               static::do_print( $str );
       }

С добавлением static::, сценарий вернёт строку “Child says Hello”.

_callstatic

До сих пор PHP поддерживает несколько чудесных методов в классе, известные вам как _set, _get и _call. В PHP 5.3 появился метод _callstatic, который работает так же как и метод _call, но занимается статическим контентом. В других словах, метод действует в непризнанных статических вызовах напрямую в классе.

Пример ниже показывает эту идею:

<?php

class Factory {

       static function GetDatabaseHandle() {
               echo '<p>Returns a database handle</p>';
       }

       static function __callstatic( $methodname, $args ) {
               echo '<p>Unknown static method <strong>' . $methodname . '</strong>' .
                       ' called with parameters:</p>';
               echo '<pre>' . print_r( $args, true ) . '</pre>';
       }
}

Factory::GetDatabaseHandle();
Factory::CreateUser();
Factory::CreateBlogPost( 'Author', 'Post Title', 'Post Body' );

Переменные статические вызовы

Когда статический член или метод не статический? Тогда это динамическая ссылка конечно!

Ещё раз, это возможность, которая приносит объектную функциональность в ваши классы. К дополнению к переменным и вызовов переменных методов, у вас есть переменные статические вызовы. Возмём класс Factory с предыдущего раздела. Вы можете получить такой же результат с помощью этого кода:

$classname = 'Factory';
$methodname = 'CreateUser';
$classname::$methodname();

$methodname = 'CreateBlogPost';
$author = 'Author';
$posttitle = 'Post Title';
$postbody = 'Post Body';

$classname::$methodname( $author, $posttitle, $postbody );

Вы можете создать динамические пространства имён примерно так:

<?php
require_once( 'lib/autoload.php' );

$class = 'MyCompany::Blog::User';
$user = new $class();
$user->set('fullname', 'Ben Balbo');
$user->save();

Эти маленькие штрихи могут сделать ваш код более читаемым и даст вам полную гибкость в объектно-ориентированном смысле.

Родной драйвер MySQL

До версии 5.3, любые соединения с MySQL обычно происходили в связке с libmysql – клиентской библиотекой MySQL.

Родной драйвер для PHP 5.3 был разработан с нуля для PHP и Zend Engine, который будет иметь несколько преимуществ. Наиболее очевидным есть то, что драйвер специфичен для PHP и по-этому оптимизирован под Zend Engine. Он предоставляет клиент с маленьким footprint и быстрым временем выполнения.

Во-вторых, родной драйвер даёт возможность использовать планировщик памяти Zend Engine и будет подчинятся настройкам параметров ограничения памяти PHP.

Родной драйвер будет лицензирован под лицензией PHP дабы избежать проблем с лицензированием.

Дополнительные функции OpenSSH

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

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

Это будет хорошая новость для тех, кто, что в настоящее время работает с OpenID.

Улучшения поддержки параметров командной строки

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

Например, функция PHP getopt() has been around for a while (!!!), но была ограничена на некоторых системах: в большинстве случаев, она не работала в Windows.

Начиная с PHP 5.3 функция getopt() не зависит от системы. Ура!

XSLT профайлинг

XSLT – это сложный зверь, и большинство пользователей этого шаблонного механизма знакомы с опциями профайлинга xsltproc. Начиная с 5.3 вы можете заниматься профайлингом ваших сценарием без этого инструмента. Этот фрагмент из примера[4], который сопровождает эту статью, дает представление о том, каким образом мы могли бы использовать это:

$doc = new DOMDocument();
$xsl = new XSLTProcessor();

$doc->load('./lib/collection.xsl');
$xsl->importStyleSheet($doc);

$doc->load('./lib/collection.xml');
$xsl->setProfiling("/tmp/xslt-profiling.txt");
echo $xsl->transformToXML($doc);

echo '<h2>Profile report</h2>';
echo '<pre>' . file_get_contents( '/tmp/xslt-profiling.txt' ) . '</pre>';

Результат профайлинга мог бы выглядеть где-то так:

number    match    name   mode     Calls   Tot  100us  Avg
0         collection                    1       4       4
1         cd                            2       1       0

          Total                         3       5

Новые уровни ошибок

PHP, конечно, имеет несколько каламбуров. Например, почему E_ALL не содержит все уровни ошибок?

Ну сейчас уже делает! Да, E_STRICT теперь часть E_ALL.

Кроме того, пока E_STRICT используется для информирования функциональности, которая может быть не рекомендуемой в ближайшем будущем, как, например, определения абстрактного статического метода, то в PHP 5.3 эти 2 ошибки делятся на E_DEPRECATED на E_STRICT соответственно, что больше подходит по смыслу.

Другие мелкие улучшения

Вот горсточка улучшений, которые появились в PHP 5.3, которые малы даже для параграфа, или были не стабильны во время написания этой статьи:

• Sqlite3 поддерживается расширением ext/sqlite
• В DirectoryIterator SPL реализован ArrayAccess
• 2 новых функции: array_replace и array_replace_recursive. Пока эти функции не определены под PHP 5.3, но в коде на C, который их реализует, с виду их функциональность похожа на array_merge(). Одно исключение составляет функция array_replace(), которая будет обновлять значения в первом массиве, когда значения ключей в обоих массивах одинаковые. Значения ключей, которые есть в втором массиве, но нет в первом, будут игнорироваться.

Резюме

PHP 5.3 содержит много функциональности, которые намечались только в PHP 6, дабы стать маленьким обновлением для большого релиза, который каждый PHP разработчик должен знать. Мы затронули большинство возможностей в этой статье, привели несколько примеров кода, который показывает как вы можете использовать эти возможности.

Не забудьте скачать код, супуствующий этой заметке [12], и быть в курсе событий

[1] http://snaps.php.net/
[2] http://www.sitepoint.com/examples/php5/PHPdemos.zip
[3] http://phpmelb.org/index.php?option=com_content&view=article&id=69&Itemid=1
[4] http://www.sitepoint.com/examples/php5/PHPdemos.zip
[5] http://www.sitepoint.com/examples/php5/PHPdemos.zip

Но когда я попробывал 11, то сразу бросилась в глаза скорость работы. Теперь всё происходило мгновенно! Вот и видео подтверждение:

И это чистейшая правда. Вот и тест провели, а я попробую перевести.

Yum таки не вкусняшка. Включивши питон, я так и не сумел запустить yum. Ух ты 120 MB на виртуальной машине, чтобы установить несколько пакетов. Неплохо, учитывая 128 MB на основной машине. Гавняно.

Хм, я должен попробовать xubuntu – или это будет таким же дрянным и вздутым и загубленым питоном poo?

Поскольку все наши усилия были направлены на то, чтобы сделать ZYpp быстрее, путём обьединения и интеграции Michael Schroeder’s вместе Michael Matz, который смног сделал в solv файлах и для хранения данных,то мне никогда не хотелось сделать “быстрое сравнение” о использовании памяти или скорости. Так давайте уже взглянем.

Вот мои репозитарии:

Software configuration management (openSUSE_10.3)
10.3 - Main Repository (NON-OSS)
10.3 - Packman
openSUSE-10.3-Updates
Virtualization:VirtualBox
home:dgollub
KDE:KDE3
Mozilla based projects (openSUSE_10.3)
ZYPP SVN Builds (openSUSE_10.3)
ZYPP SVN Builds (openSUSE_10.3)
home:prusnak
10.3 - VideoLan
openSUSE.org tools (openSUSE_10.3)
SUSE Feature Tracking Tool (openSUSE_10.3)
psmt's Home Project (openSUSE_10.3)
openSUSE:10.3
Duncan Mac-Vicar SUSE rpms (openSUSE_10.3)
Latest YaST svn snapshots (openSUSE_10.3)
building/openSUSE_10.3

Во всех этих репозитариях приблизительно 41 тис. пакетов.

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

# rm -rf /etc/yum.repos.d/
# ln -s /etc/zypp/repos.d /etc/yum.repos.d

*NOTE:* I tested with yum 3.2.4. I know 3.2.14 is available, but that is what I had installed when doing the test. After doing this tests I upgraded to 3.2.14 but it did not accept my .repo file because the character “:” in repo names. However the changelog of yum since 3.2.4 shows: If using latest yum would invalidate this numbers (not as in 1 second, but as in an order of magnitude), let me know and I will repeat them when I make them work with my repo files. (не переводил, зачеркнули же. Говорится о версиях, и чего не на новых… )

Update 14.05.2008 : Я добавил yum 3.2.14. Тем не менее его производительность даже хуже, но не использование памяти.

Update 15.05.2008 : добавлены цифры дял smart 0.52

libzypp – тот который лежит в factory уже несколько дней: 4.21.1.

yum и ZYpp ведут себя по-разному, yum скачивает и парсит файлы filelists.xml и other.xml, а мы их игнорируем. Так что, я пропустил часть загрузки мета данных и засёк время построения кэша.

# yum clean dbcache
...
19 sqlite files removed

# time yum makecache
...
Metadata Cache Created

real    9m41.036s
user    2m34.766s
sys     0m11.545s

Почти 10 минут. В это время включен разбор двух больших файлов, которые мы прогнорировали. Я запустил его ещё раз, нажавши Ctrl+C, когда yum закончил обрабатывать первичные данные, как это делает zypp.

# time yum makecache
...
Exiting on user cancel

real    4m6.730s
user    0m34.058s
sys     0m3.080s

И очередь ZYpp:

# time zypper ref -B
...
All repositories have been refreshed.

real    0m18.472s
user    0m16.029s
sys     0m2.024s

Таким образом Yum требует технически в 13 раз больше времени чем ZYpp (если рассматривать одинакувую работу), но пользователь ждёт в 30 раз больше.

Теперь установка пакетов. Это означает время от вопроса “Продолжить (да/нет)” до приглашения оболочки.

# time yum install fate
...
Is this ok [y/N]: n
Exiting on user Command
Complete!

real    0m19.143s
user    0m14.057s
sys     0m1.920s

А ZYpp

# time zypper in fate
...
Continue? [YES/no]: n

real    0m9.796s
user    0m8.509s
sys     0m0.624s

На этом этапе ZYpp всего в два раза быстрее Yum. Всего

Что же нас ждёть, когда захочется обновить пакеты?

# time yum upgrade
...
real    0m45.152s
user    0m36.894s
sys     0m7.476s

(Замечание: yum даже не нашёл ничего для обновления).

# time zypper update
...
Continue? [YES/no]: n

real    0m8.988s
user    0m7.820s
sys     0m0.596s

yum нужно в 4 раза больше времени чем ZYpp, чтобы определить работу для обновления.

Update 14.05.2008 : сравнивал update с upgrade, я исправил это в диаграме. Тем не менее, у меня небыло данных для update в старом yum.

• 
• Резюме.

Теперь, сколько памяти каждому с них требуется? Для этого я просто проверил установку одного пакета используя valgrind massif, профайлера кучи (heap profiler).

• 
• Использование памяти Yum
• 
• Использование памяти ZYpp
• 
• Update 14.05.2008 : диаграмма использования памяти yum 3.2.14
• 
• Update 15.05.2008 : диаграмма использования памяти smart 0.52

Ви можете сделать вывод, что ZYpp потребляет чуть больше 20M, в то время как yum использует больше 180M памяти, тоесть в 9 раз больше. Обновлено 14.05.2008 : yum 3.2.14 использует приблизительно 160 в худший момент времени.

Мне было бы интерестно поссмотреть и на использование процессора, но это уже позже. Что вы думаете об этом?

В предыдущий раз рассматривали метод очереди событий, как полностью клиентскую реализацию лёгкой многоуровневой функции отмены. Я упоминал о паре обмолвок: это не работает в многопользовательской среде и не работает в время-зависимых событиях, как отправка email. Я пропустил существенную оговорку, на которой обратил внимание один с моих читателей, Alexander Botero-Lowry: два таба, в которых открыта одна и та же страница, не синхронизируются. Я написал, как это решить с помощью cookies [ перевод ].

На этот раз, давайте взглянем на решение Отмены для срочных действий. В методе очереди событий, мы могли бы подождать, пока событие “onunload” синхронизирует действия пользователя на стороне клиента с серверной стороной. Для срочных действий, таких как отправка email, у нас нет такой роскоши. Хуже всего, что email – это не push-технология. Отправивши раз email по диким трубам Internet, оно уже не может быть не отправленным.* Для несчастных, которые нажали “отправить” и лишь потом осознали, что переслали томное любовное письмо своему боссу, остаётся надеяться на перебои с электроэнергией и спам-фильтры. Учитывая, как часто спам проходит последние мои фильтры, перспективы не столь хороши.

Электронные письма нужно отправлять вскоре после того, как пользователь нажал на “Отправить” и операцию отправки нельзя отменить. Что мы можем сделать?

Для решения данной проблемы мы должны обратится к интерфейсу на основе времени. Как правило, интерфейсы на основе времени не в состоянии быть действительно годным к употреблению, потому что расчёт времени, в действительности, неправильный. Для некоторых людей оно слишком быстро, для других – медленно. Даже ваше собственное восприятие изменений времени основанно на вашей умственной нагрузке. Когда вы о о чём-то сильно думаете, вы не замечаете течение времени: что было слишком медленно прежде, теперь будет слишком быстрым. Старая поговорка: “Время летит, когда вы веселитесь” действительна для пользовательского интерфейса. Хорошим примером недостатка интерфейса на основе времени можно увидеть в наборе текста в мобильных телефонах, но эта тема подождёт до следующей заметки.

Когда посылается письмо, как правило в период “‘о, НЕТ! секунду“— доли секунды после нажатия “отправить” — вы понимаете, что отправили письмо на неправильный адрес. Желание не посылать электронную почту, которую послали час назад, происходит, но с намного меньшей частотой. Таким образом, решение на основе времени, когда пользователь может не послать письмо, имеет смысл только на коротком промежутке времени: back-end может просто отложить посылку письма на 30-60 секунд и, если пользователь захочет отменить отправку на протяжении нормального периода времени, back-end уберёт с очереди email и письмо не отправится.

Теперь, я не особенно счастлив с поддержкой интерфейса на основе времени, но я зажат ограничениями. С одной стороны, отправка электронной почты в реальном мире, действие, которое невозможно отменить. С другой стороны, письма надо отправлять живчиком. Функция отмены для срочных событий не является канонической проблемой и единственное решение, которое я вижу – это компромисс (если кто-то знает другое решение, я весь во внимании!). В целом, многие ситуации, в которой мы, как проектировщики, попадали с непроходимыми препятствиями. Лучшее, что мы можем сделать – разрабатывать системы, которые заботятся о наиболее вероятно использованных случаях, и позволяет пользователям изящно вернуться из наиболее распространенных ошибок. Undo на основе времени не решит всех недостатков отмены отправки письма ( это не будет помогать с ночными электронными письмами, Вы обнаружите, что послали следующим утром), но он будет ловить большинство ошибочно отправленных писем (ошибки типа “‘о, нет!’ секунду!” и вариант “Я-нажал-на-кнопку-случайно”). И это поймает намного больше ошибочных писем, чем банальное оповещение. Оказалось, что Paul Buchheit, создатель Gmail, тоже так думает. Как жаль, что это не было реализовано— это низковисячие фрукты, которые могли бы дать Gmail больший перевес в его превосходстве.

Не так то и много там этого метода. Для реализации его в стиле Ajax, вам просто понадобится mutex и таймер. Когда время истекает (или при переходе со страницы), письмо будет отправлено. Более продвинутый способ предполагает установление флага на сервере наряду с серверным обратным отсчётом. В сложной частью всего этого дело заключается в том, чтобы указать время, оставшееся таким образом, чтобы не запугать пользователей. Например, обратный отсчёт времени вызывает внутреннее чувство паники:

Не хорошее чувство, неправда-ли? Взамен, медленное затухание работает лучше:

Обратный отсчет, который не начинает считать в обратном порядке до последних 10 секунд, мог бы также работать. Это прекрасная задача – разработать механизмы красивого отображения лимита времени для отмены. Поделитесь своими мыслями в разделе комментариев. Бонусы за предложения любого вида!

В следующий раз я буду говорить о некоторых искусных, более надежных методах введения Отмены с помощью Ajax.

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

Перевод: Undo Made Easy with Ajax (Part 2): Time-Sensitive Actions