Ответ 1
Я думаю, что это хорошая идея, заслуживающая внимания.
Вопрос о том, с какими функциями следует работать и что должно быть ошибкой, сложно провести линию. С одной стороны, язык может быть чрезмерно разрешительным (JavaScript?) До такой степени, что он позволяет вам навредить себе. На другом конце это может быть настолько предписывающим, что вы остаетесь без мощных абстракций, которые составляют (C?).
В этом конкретном случае мы торгуем с возможностью обнаружения ошибки, когда вы пишете код, который ожидает карту, но передается вектор; в отличие от возможности писать более общий код. Лично мне нравится, что это рассматривается как ошибка, потому что иногда я передаю неправильный тип коллекции функции и предпочитаю, чтобы она взорвалась, чем что-то делать.
Мне было бы странно называть keys вектором, потому что вектор не имеет ключей, он индексируется. Для меня это разные вещи. Поэтому, если я пишу код, который вызывает keys на векторе, это, вероятно, ошибка. Если я действительно хочу, чтобы диапазон был того же размера, что и счет вектора, я бы это явно написал. И если бы я хотел иметь функцию, которая могла бы обрабатывать как карты, так и векторы, я бы использовал условный тип для выбора ключей или подсчета диапазонов. Очевидно, это только мои предпочтения, но для меня они являются серьезной причиной, чтобы не хотеть keys работать над векторами. В частности, причина в том, что я хочу обнаружить ошибки.
Однако вполне понятно, что вы предпочли бы, чтобы он работал с векторами, видя, что они являются ассоциативными по индексу.
Как и в случае dissoc, кто-то может потребовать, почему нет? (dissoc [1 2 3] 0) -> [2 3]) Есть проблема с производительностью, потому что вы не можете удалить элементы в O (1), ну, действительно, если Clojure принят rbb-vector, Это очень удобно иногда, когда вам нужно выполнить эту операцию. что-то нужно делать людям, и это довольно уродливо и непрозрачно в Clojure! Никто из нас не хочет, чтобы это была функция, но я уверен, что в некоторых ситуациях она будет очень изящной. Но на самом деле это не случайное ограничение, мы просто так предпочитаем.
Clojure имеет открытый вклад, который сводится к: Обсудите, что вы пытаетесь сделать с другими в группе Clojure Dev Google. Theyre, вероятно, сможет предложить комментарии и предложения, которые приведут к более качественным изменениям и более плавному процессу подачи. После того, как вы отправили CA, вы можете отправлять патчи через JIRA.
Любой может отправить запрос об ошибке или расширении на Clojure. Любой, кто подписал соглашение о спонсорстве, может предоставить исправления или работать над улучшением билетов. Проселочным лицам была предоставлена возможность переместить билеты через (некоторые из) этапов процесса. BDFL - Рик Хикки - создатель и доброжелательный диктатор для жизни того, что входит в Clojure. Стюарт Хэллоуэй также имеет специальный уровень доступа и обычно фиксирует исправления до Clojure.
Если вы считаете, что это будет хорошим изменением на Clojure, я рекомендую сначала обсудить его в группе Clojure, чтобы получить некоторую поддержку идеи, а затем привести ее в группу Clojure Dev. Как правило, ваша идея будет лучше всего воспринята, если есть поддерживающие артефакты, такие как "Здесь большой пример использования, где он демонстрирует ценность" и "Здесь обсуждается, где другие люди желают одного и того же ценностного предложения".