Это не больший «блокер», чем использование npm в ноде, которая тоже не часть node.js как такового. Такие вещи совершенно не обязаны поддерживаться на уровне языка, они прекрасно реализуются сторонними приложениями. Go сам по себе даёт концепцию GOPATH, а какие версии и как вы в него положите — это ваше дело и ваша свобода. Инструментов для точного контроля версий — масса github.com/golang/go/wiki/PackageManagementTools
Автор, не хочется Вас расстраивать (хотя выше уже расстроили), но Ваш компас указывает не на Мекку. Вы используете, по сути, меркарторовы координаты, а прямая в этих координатах (локсодрома) не является прямой (кратчайшим расстоянием, геодезической, ортодромой) на сфере.
Например, прямое (на сфере) направление на Мекку из Нью-Йорка выглядит так: yadi.sk/i/pKdLZT9IeMj49 (красная кривая). А синяя прямая — это, что получается по Вашему алгоритму. Сами видите, какая разница.
О боже. Слушайте, зачем вам вообще формат? Ло́жьте бинарные данные в файл подряд, клиентский код сам разберётся. Ведь «логика обработки данных — это всегда дело приложения».
Ну слушайте, если пост всё равно писался ради последней ссылки, то хоть расскажите, чем хороша ваша система, как ей пользоваться, чем лучше конкурентов… А то блаблабла и вдруг гитхаб.
Попробую переписать табличку из поста с учётом обсуждения:
Человекопонятность — 3 (есть проблемы с пониманием, где ключ, а где значение, почему нужен пробел перед равенством, а после не нужен и т. п. — требует довольно строгого парсера в голове. Плюс, бинарные данные не человекопонятны, в отличие от конкурентов)
Удобство редактирования — 2 (для редактирования человеком требуется предварительная специальная настройка текстового редактора, да ещё и не всякий редактор позволит редактировать произвольные бинарные данные. Ни у одного конкурента таких проблем нет.)
Бинарная безопасность — 1 (теоретически формат поддерживает бинарные данные, на практике их очень легко «сломать», а какие-либо проверки целостности отсутствуют)
Произвольная иерархия — 5
Простота реализации — 5
Скорость парсинга/сериализации — 5 (на уровне конкурентов)
Размер в сериализованном виде — 5 (на уровне конкурентов)
Поддержка поточной обработки — 5 (на уровне конкурентов)
Распространённость — 0 (не имеет смысла, формат новый)
Поддержка редакторами — 1 (не имеет смысла, формат новый)
Поддержка языками программирования — 1 (не имеет смысла, формат новый)
Простой язык структурированных данных — это очень хорошо. Вложенность индентацией — это тоже хорошо. Но есть и то, что плохо, причём очень:
1. Требование индентирования непременно табуляцией.
2. Требование завершения строк непременно 0D
Эти требования (любое из них) приводят к тому, что после открытия-правки-сохранения файла в произвольном текстовом редакторе мы с высокой вероятностью получим некорректный файл, при том что визуально он не будет отличаться от корректного. Это Очень Большой Недостаток, сразу ставящий на формате крест.
Я, кстати, не вижу никаких сложностей в разрешении и пробелов и табуляции (естественно, не в смеси) в п. 1. и 0A 0D в п. 2. Понятно, что это порушит светлую мечту о прямой записи произвольных бинарных данных, но, как уже сказали выше, с такой записью всё равно проблемы — величину, состоящую из пробельных символов никак нельзя контролировать и вообще увидеть. Я бы предложил автору сначала вообще оценить важность этой задачи — записи бинарных данных без кодирования. Мне кажется, она сильно преувеличиена, недаром ни в одном примере в статье не используется ничего сверх обычного UTF-8…
Обнимемся, коллега. Причём ведь никакой же срочной необходимости «улучшать» именно эту функцию не было. Просто у кого-то улучшалка зачесалась — и сломали совместимость на ровном месте.
Суть коммента achekalin была как раз в этом — в PHP считается *нормальным* делать минорные версии несовместимыми. Хотя по правилам семантического версионирования, обновление 5.3 → 5.4 является минорным, и совместимость оно рушить не должно.
> Можете привести пример где в минорном релизе ломается совместимость?
Пример:
В функции htmlspecialchars есть параметр $encoding. Его значение по умолчанию — ISO-8859-1 для PHP до версии 5.4.0, и UTF-8 начиная с версии 5.4.0. Если строка содержит некорректные (в данной кодировке) символы, то функция возвращает пустую строку.
Если у вас строки имеют кодировку _не_ UTF-8 (1251, например) и вы используете эту функцию с параметром $encoding по умолчанию, то при переходе на php 5.4.0 все строки станут некорректными с точки зрения htmlspecialchars, и вывод этой функции обнулится.
Является ли ноль натуральным числом — этот вопрос в разных школах (не общеобразовательных, а научных) решается по-разному:)
Можно сказать «отношение целого к положительному целому». Но я в любом случае сомневаюсь, что ответ «отношение двух целых» заслуживает двойки на _вступительных_ экзаменах.
В Постгресе немного сложнее иерархия, а именно: cluster (собственно инсталляция постгрес-сервера, он один) → database (много в кластере) → schema (много в базе).
Например, прямое (на сфере) направление на Мекку из Нью-Йорка выглядит так: yadi.sk/i/pKdLZT9IeMj49 (красная кривая). А синяя прямая — это, что получается по Вашему алгоритму. Сами видите, какая разница.
С ума сойти, всего три дня коллективных усилий Хабражителей — и Вы сдвинули свою точку зрения на два микрона. Значит, есть надежда:)
Человекопонятность — 3 (есть проблемы с пониманием, где ключ, а где значение, почему нужен пробел перед равенством, а после не нужен и т. п. — требует довольно строгого парсера в голове. Плюс, бинарные данные не человекопонятны, в отличие от конкурентов)
Удобство редактирования — 2 (для редактирования человеком требуется предварительная специальная настройка текстового редактора, да ещё и не всякий редактор позволит редактировать произвольные бинарные данные. Ни у одного конкурента таких проблем нет.)
Бинарная безопасность — 1 (теоретически формат поддерживает бинарные данные, на практике их очень легко «сломать», а какие-либо проверки целостности отсутствуют)
Произвольная иерархия — 5
Простота реализации — 5
Скорость парсинга/сериализации — 5 (на уровне конкурентов)
Размер в сериализованном виде — 5 (на уровне конкурентов)
Поддержка поточной обработки — 5 (на уровне конкурентов)
Распространённость — 0 (не имеет смысла, формат новый)
Поддержка редакторами — 1 (не имеет смысла, формат новый)
Поддержка языками программирования — 1 (не имеет смысла, формат новый)
1. Требование индентирования непременно табуляцией.
2. Требование завершения строк непременно 0D
Эти требования (любое из них) приводят к тому, что после открытия-правки-сохранения файла в произвольном текстовом редакторе мы с высокой вероятностью получим некорректный файл, при том что визуально он не будет отличаться от корректного. Это Очень Большой Недостаток, сразу ставящий на формате крест.
Я, кстати, не вижу никаких сложностей в разрешении и пробелов и табуляции (естественно, не в смеси) в п. 1. и 0A 0D в п. 2. Понятно, что это порушит светлую мечту о прямой записи произвольных бинарных данных, но, как уже сказали выше, с такой записью всё равно проблемы — величину, состоящую из пробельных символов никак нельзя контролировать и вообще увидеть. Я бы предложил автору сначала вообще оценить важность этой задачи — записи бинарных данных без кодирования. Мне кажется, она сильно преувеличиена, недаром ни в одном примере в статье не используется ничего сверх обычного UTF-8…
Пример:
В функции htmlspecialchars есть параметр $encoding. Его значение по умолчанию — ISO-8859-1 для PHP до версии 5.4.0, и UTF-8 начиная с версии 5.4.0. Если строка содержит некорректные (в данной кодировке) символы, то функция возвращает пустую строку.
Если у вас строки имеют кодировку _не_ UTF-8 (1251, например) и вы используете эту функцию с параметром $encoding по умолчанию, то при переходе на php 5.4.0 все строки станут некорректными с точки зрения htmlspecialchars, и вывод этой функции обнулится.
Можно сказать «отношение целого к положительному целому». Но я в любом случае сомневаюсь, что ответ «отношение двух целых» заслуживает двойки на _вступительных_ экзаменах.