Вышел Ruby 2.3.3

Слияние хэшмапов нужно, а antigravity — не очень.

Нужны. В Ubuntu LTS 16.04 есть MRI 2.3 в репозиториях.

Если для какого-нибудь дистра нет в репозиториях, то несложно собрать самому с помощью ruby-build.

ты пробовал? реально в дистр пятилетней давности собрать все руби, с всеми зависимостями, доп-пакетами, вместе с msf?

И как оно дышится? Легко?

ты пробовал? реально в дистр пятилетней давности собрать все руби, с всеми зависимостями, доп-пакетами, вместе с msf?

Я не пробовал все, но собирал много разных Ruby для Debian Squeeze, когда он был stable, потому что в репозиториях — очень старая версия.

msf мне не требовался, но там ничего затруднительного. Проблем возникнуть не должно.

И как оно дышится? Легко?

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

Слияние хэшмапов нужно

... и делается в две строчки. Но зачем заставлять погромистов иногда думать, лучше покрыть все их хотелки, даже самые примитивные, искоробочными решениями. Если это путь Руби, то путь Питона несколько иной.

Но зачем заставлять погромистов иногда думать, лучше покрыть все их хотелки, даже самые примитивные, искоробочными решениями. Если это путь Руби, то путь Питона несколько иной.

Путь Питона заключается в том, чтобы заставлять разработчиков думать о Питоне вместо того, чтобы решать свои задачи?

... и делается в две строчки.

В три:

context = {}
context.update(defaults)
context.update(user)

context = {**defaults, **user}

Мне жаль, что Питон вызывает у кого-то раздражение.

context = {}
for d in defaults, user: context.update(d)

context = {**defaults, **user}

нет стандартной intersection

Для меня функция/метод в стандартных либах вполне может быть очевидна.

А что такое «прозрачность»?

См. ниже.

Может быть, вам нужно каждый раз, когда возникает позыв написать dict.update(other_dict), писать

С таким подходом шланга у тебя нет шансов. Моя позиция четко изложена на примере dict.update в блоке итогов, и съезжать ты будешь с горки на санках, а не здесь:

Вышел Ruby 2.3.3 (комментарий)

Т.е. если бы я даже не знал этого метода, и у меня под рукой (OH SHI~!) нет доков, я бы заюзал его спокойно. Мне даже название метода не нужно знать. Я бы сразу попробовал update – и все прокатило бы на ура. Просто и прозрачно. В отличии от stupid_name_method/stupid_name_method!/stupid_name_method?/etc. Иди дальше зубри свои правила наименований, и упивайся ненужной «лаконичностью», погромист.

Слияние хэшмапов нужно, а antigravity — не очень.

Погромист определяет нужность или ненужность _инструментов_. «Молоток нужен всем – электропила нужна при крайней необходимости!» Боже, как это мило.

А можно и в одну, но тогда уже выглядеть будет плохо.

Оно будет выглядеть плохо вне зависимости от количества строк.

Я бы сразу попробовал update – и все прокатило бы на ура.

А если вам нужно не in-place?

Погромист определяет нужность или ненужность _инструментов_.

Это же просто паскалка. Зачем вам нужен этот «инструмент»?

Нет, с фанатиками я не спорю.

context = {}
for d in defaults, user: context.update(d)

выглядит отвратительно. Это очень неудобно по сравнению с

context = defaults.merge user

Это инструмент привлечения адептов же. В конечном итоге, всем юзающим питон он нужен.

А вот ситуацию в студию, где без этого не обойтись?

А вот ситуацию в студию, где без этого не обойтись?

Вот же. Обойтись можно.

Вот же.

И что там? Если нужно именно !in-place (ниже еще раз обмусоливается вопрос «зачем», ибо твое «просто так хочу» никому не интересно):

context = defaults.copy()
defaults.update(user)

Обойтись можно.

Ага, а теперь пойми, что ты дал сферического коняую ситуацию в вакууме, я же тебя спрашиваю о _реальной ситуации_ в проекте, когда тебе нужно юзать _именно !in-place. Насколько я понимаю, таких ситуаций у тебя нет, и все это сводится в итоге к «просто я так могу»? В этом есть _конкретный смысл_ или нет?

Про новый сахар с 3.5+ уже сказали (**), если тебе именно _лаконично_ (тьфу ты) нужно.

Мне нужно удобно.

Насколько я понимаю, таких ситуаций у тебя нет, и все это сводится в итоге к «просто я так могу»?

Я не меняю состояния объектов без необходимости и считаю это хорошей практикой. Пример реальной ситуации:

# Create a new renderer for the same controller but with new defaults.
def with_defaults(defaults)
  self.class.new controller, env, self.defaults.merge(defaults)
end

В конечном итоге, всем юзающим питон он нужен.

Это угроза? Надеюсь, со мной ничего не случится.

Мне нужно удобно.

Что конкретно неудобного в предложенных способах?

Я не меняю состояния объектов без необходимости и считаю это хорошей практикой.

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

static VALUE
rb_hash_merge(VALUE hash1, VALUE hash2)
{
    return rb_hash_update(rb_obj_dup(hash1), hash2);
}

Это угроза? Надеюсь, со мной ничего не случится.

http://comicsia.ru/i/1c/03-7171.png
Нет, это о том, что привлекая внимание к языку, сообщество быстрее растет и развивается, и прочие блаблабла.

Что конкретно неудобного в предложенных способах?
Только вот скопировать self.defaults и обновить его уже с аргументом метода ты мог бы и сам

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

Ну да, удобно, круто, метод сэкономил тебе аж _джва вызова_, но очевидность-то причем?

Когда «merge» делает «merge» — это очевидно. Когда есть много разных способов сделать «merge»(ни один из которых не называется «merge») — это не очень очевидно.

Нет, это о том, что привлекая внимание к языку, сообщество быстрее растет и развивается, и прочие блаблабла.

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

Когда «merge» делает «merge» — это очевидно.

#define очевидность-то? Ибо когда слияние делает копирование+обновление – для меня это не очевидное слияние. Лично я хотел бы видеть объединение двух объектов в один _из_, а не в один _новый_.

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

Какая проблема для программиста, ага.

Становясь адептом чего-либо, можно непроизвольно утратить способность трезво оценивать альтернативы.

Ну дак не становись адептом и трезво оценивай альтернативы :) Лично я уже говорил, что пистон юзаю чисто для мелкой автоматизации (наколенные скрипты). Но я не начну писать их на руби, только потому, что там есть метод merge, а в пистоне нет. Довольно _трезвая оценка_, ИМХО.

#define очевидность-то?

Когда не нужно смотреть имплементацию, чтобы понять, что делает.

Какая проблема для программиста, ага.

There are only two hard things in CS.

Когда не нужно смотреть имплементацию, чтобы понять, что делает.

Так, а для dict.update тебе нужно было смотреть имплементацию, или ты о каких конкретно методах?

There are only two hard things in CS.

naming things and cache invalidation? :)

Всегда считал это каким-то старым стереотипом, по крайней мере для меня это не проблема. Но вот копирование – это довольно частая операция, как для программиста. Гнушаться ее уж точно не стоит, хотя я ничего не говорю, если есть метод merge – почему бы и не использовать, я ж не против :)

Так, а для dict.update тебе нужно было смотреть имплементацию, или ты о каких конкретно методах?

Нет, dict.update — это тоже очевидно. Другое дело, что в большинстве случаев мне не понадобится менять состояние.

Но вот копирование – это довольно частая операция

Ruby продуман таким образом, что нет.

Другое дело, что в большинстве случаев мне не понадобится менять состояние.

Не знаю почему ты решил, что слияние – это обязательно создание нового объекта. Лично я, когда делаю слияние (в том же git) – привык думать, что изменяю _текущий_ бранч (куда сливаю изменения). Почему для меня это очевиднее. Таки не задефайнена очевидность-то, если возвращаться к первоочередному вопросу?

Не знаю почему ты решил, что слияние – это обязательно создание нового объекта.

Не обязательно. Есть как Hash#merge, так и Hash#merge!.

Лично я, когда делаю слияние (в том же git) – привык думать, что изменяю _текущий_ бранч (куда сливаю изменения).

А если у вас не fast forward, то что происходит?

А если у вас не fast forward, то что происходит?

Если коммит не является предком, то тут как раз-таки и _очевидно_ порождение нового коммита. Иначе встает банальный вопрос: как? Но к вашим объектам в Ruby-то это как относится? У вас часто бывает такое с объектами? :) fast-forward юзается по умолчанию, и этого вам уже должно быть достаточно для понимания работы слияния. А вот все остальное уже -> в документацию.

Не обязательно. Есть как Hash#merge, так и Hash#merge!.

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

P.S. Python - норм. Лютый идеологический хейт из разряда «краем уха слышал» - не норм.

Два чая этому господину