[Moscow.pm] Encode: danko gay, все геи - вредители!

[Nikolay Poletaev]

Не вижу проблемы, да, что-то изменили, но перед тем как обновляться, стоит
ИМХО почитать change log и еще раз подумать, а точно ли надо обновляться?

ср, 19 окт. 2016 г. в 1:09, Victor Efimov <victor на vsespb.ru>:

> 18 октября 2016 г., 22:50 пользователь Ivan Petrov
> <i.petro.77.00 на gmail.com> написал:
> >>> к какому улучшению?
> >>> имеется туева хуча кода работающего с языками которая полагается на то
> >>> что decode_utf8 не выбросит ексепшена на валидном юникоде.
> >>> приходит эстет (зачеркнуто) гей и вместо того чтобы поправить
> >>> документацию и зафиксировать в ней текущее положение вещей,
> >>> исправляет, меняет зафиксированное до этого на более чем 15 лет
> >>> поведение!
> >
> >> Ну так как ты не читал документацию к Perl и твой код - один сплошной
> >> баг, то улучшение и исправление багов в perl вызывают поломку твоего
> >> кода. Ты при этом настолько профнепригоден, что не можешь этого понять
> >> и даже MR с описанием фикса не наводят тебя на мысль, что ты что-то
> >> делаешь не так.
> >
> > MR с описанием фикса чего?
> > там чисто эстетический "фикс". Который более правильно назвать
>
> Это не эстетический фикс, это фикс реального бага, пример тест-кейза здесь
> https://rt.cpan.org/Public/Bug/Display.html?id=87267#txn-1250086
>
> > поломкой.
> > Если 15+ лет одна из базовых функций ведет себя определенным образом,
> > то менять ее поведение НЕЛЬЗЯ.
> > см. Например спор Дреппера с Линусом Торвальдсом: первый говорил
> > - мои эстетические чуйства требуют изменить поведение memcpy,
> > а второй говорил
> > - но имеется 100500 кода, который полагается на текущее (более
> >   чем 25 лет постоянное) поведение и эту вашу эстетику надо засунуть в
> >   одно место. И вообще у меня видео из за вашей эстетики поломалось!
>
> Сравнение с этим случаем не корректное:
> 1) в случае с линуксом идёт речь о том чтобы сделать workaround в
> багжному коду юзеров, ничего не сломав,
> в нашем случае ничего не сломать нельзя (оно и было сломано до этого фикса)
> 2) в случае с линуксом функция могла бы проверять что её вызывают с
> неправильными данными, она этого не делала. в нашем
> случае проверка не возможна - в этом суть юникода perl - нельзя в
> общем случае отличить текст от бинарных данных (да, utf8 флаг ничего
> не говорит
> о том текст это в юникоде или нет). Хотя.. это сложно объяснить как
> раз русскоязычному юзеру, ибо такие проблемы только с Latin1
> 3) в линуксе в роли юзеров у которых memcpy "иногда глючит" (из-за
> того что оптимизация intel иногда проявляла себя) были юзеры после
> внесения изменения, а в нашем случае, как раз "иногда глючило" до
> внесения изменения (иногда - если у строки появлялся utf8 флаг, это
> программист плохо контроллирует, он
> может появляться "случайно")
>
> >
> > в итоге видео чинили месяцев этак шесть по репозитариям. А в ядре
> > линукс memcpy ведет себя по старому и никто от этого не страдает.
> > а код в ядерных модулях, который мог бы сломаться из за подобного
> > эстета (зачеркнуто) гея, не ломается.
> > --
> > Moscow.pm mailing list
> > moscow-pm на pm.org | http://moscow.pm.org
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20161019/35dc3e23/attachment-0001.html>