Исходное сообщение
"Спецификации HTML5 переходят к непрерывному циклу обновлений" Отправлено PereresusNeVlezaetBuggy, 25-Янв-11 17:21
>> Вообще-то о том и речь, что предлагаемый вами способ — более проблемный, чем используемый ныне. > Я бы сказал, что ныне никакого способа не используется, то есть, кто-то > проверяет используемые функции по-штучно, кто-то привязывается к версии браузера - парся > узерагент, что в сущности и предлагается прокачать, режимы совместимостимости - можно > было бы добавить для отстройки от конфликтов версий, когда функции с > одинаковым именем ведут себя по разному в разных версиях, хотя допущение > такого = ломание обратной совместимости = в стандартах не разделенных длительным > периодом времени нонсес, ноуворанти - со всеми вытекающими. Да, это недостатки текущей схемы, когда используется единый движок, в котором отдельные элементы могут работать в разных режимах, но в целом движок один, только парсеры (по сути, тупейшие конечные автоматы, или что-то эквивалентное) могут различаться. > Хорошим примером, я бы назвал libfuse, несколько версий этого самого фусе прекрасно > уживаются в одной библиотеке, и даже в одних заголовочных файлах (*.h), > переключение по #define FUSE_USE_VERSION, которая автоматом дефайнится, если не указать. У libfuse весьма простой интерфейс, который вдобавок не определяется «сверху» и поэтому, как следствие, не может содержать противоречий и т.д. Так что хотя архитектурно сравнение корректно, с точки зрения конкретной реализации — уже не очень. В одной местности почтальону лошадь будет подспорьем, в другой — с ней будет больше возни, чем от неё самой пользы...

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>> Вообще-то о том и речь, что предлагаемый вами способ — более проблемный, чем используемый ныне. >> Я бы сказал, что ныне никакого способа не используется, то есть, кто-то >> проверяет используемые функции по-штучно, кто-то привязывается к версии браузера - парся >> узерагент, что в сущности и предлагается прокачать, режимы совместимостимости - можно >> было бы добавить для отстройки от конфликтов версий, когда функции с >> одинаковым именем ведут себя по разному в разных версиях, хотя допущение >> такого = ломание обратной совместимости = в стандартах не разделенных длительным >> периодом времени нонсес, ноуворанти - со всеми вытекающими. > Да, это недостатки текущей схемы, когда используется единый движок, в котором отдельные > элементы могут работать в разных режимах, но в целом движок один, > только парсеры (по сути, тупейшие конечные автоматы, или что-то эквивалентное) могут > различаться. >> Хорошим примером, я бы назвал libfuse, несколько версий этого самого фусе прекрасно >> уживаются в одной библиотеке, и даже в одних заголовочных файлах (*.h), >> переключение по #define FUSE_USE_VERSION, которая автоматом дефайнится, если не указать. > У libfuse весьма простой интерфейс, который вдобавок не определяется «сверху» > и поэтому, как следствие, не может содержать противоречий и т.д. Так > что хотя архитектурно сравнение корректно, с точки зрения конкретной реализации — > уже не очень. В одной местности почтальону лошадь будет подспорьем, в > другой — с ней будет больше возни, чем от неё самой > пользы...
	Введите код, изображенный на картинке: