в 3.4 будет перегрузка функций, правда, игрушечная

Не нужно.

Кстати, а почему https://twitter.com/d6/status/364821225131872257 ?

Я спрашивал на SO, чем обусловлено type erasure, а в ответ - «совместимость» или «не нужно», а один наоборот сказал, что Sun просто не осилили нести в рантайме типы. Т. к. они не дали вменяемого ответа, может, здесь кто-то скажет что-то разумное? Что-то из теории CS, что объясняет, почему типы в generics затираются.

Перегрузка функций

Динамическая типизация

facepalm.jpg

Что ты несешь, епт. Какая нафиг перегрузка функций, в PEP же ясно написано - generic function, single dispatch.

Хотя фишка ненужная в таком недоделанном виде, да и в доделанном тоже сомнительная.

а почему

Я так понимаю, те кто против этого просто не хотят превращать яву в питон. На сколько правомерны их страхи я не знаю, не программирую в жабу.

чем обусловлено type erasure

ХЗ. Я буду точно так же гадать на кофейной гуще как и те у кого ты уже спрашивал.

Какая нафиг перегрузка функций

А вот, кстати, вопрос. Чем это отличается от перегрузки функций?

как и те у кого ты уже спрашивал.

Вот и мне интересно - почему те, кто отвечает, в основном ляпают что-то вроде «это плохо» и замолкают. Уж лучше, правда, молчать.

Да ничем, но это не нужно. Я не понял, почему проверка типа в рантайме является антипаттерном, кстати.

Ну, чем это плохо можно предположить. Раздувание рантайма, усложнение кода.

А чем это будет хорошо?

Я вот сейчас занимаюсь филосовствованием нужны ли вообще динамические языки. Как-нить создам отдельный тред на эту тему.

Осталось дождаться внедрения @multidispatch, и тогда питоном уже можно будет начать пользоваться :)

Чем это отличается от перегрузки функций?

Историческим багажом термина. «Single-dispatch generic functions» - это отсылка к CLOS и Dylan, «перегрузка функций» - к Си++ или даже Аде; первое - динамический механизм, второе - статический.

Перегрузка функций — костыль в отсталых языках, нужен для того, чтобы для разных типов вызывать разные методы. А в питонах не нужно, потому что утиная типизация.

лучше бы статическую типизацию сделали, сразу бы вменяемый язык стал.

Я не про динамические языки. Я наткнулся на пример, когда паттерн-матчится дженерик, и, естественно, внутренний тип недоступен. Мне просто стало интересно, почему в самом начале решели это сделать.

почему проверка типа в рантайме является антипаттерном

Потому что нарушает принципы duck typing. Тебя не должно волновать что за объект тебе передают. Это в теории.

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

Я одно время делал в коде проверку типов. Очень выручало когда нет юнит-тестов :). Потом забил.

почему в самом начале решели это сделать.

По-моему, просто не доделали :)

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

А в питонах не нужно, потому что утиная типизация.

Это позволяет менять свойства самого объекта. А вот как на этот объект будут реагировать другие объекты это другой вопрос.

Некоторым хочется безопасные динамические языки... Мне, например :)

безопасные динамические языки

А это хотя бы теоретически возможно?

в PEP же ясно написано - generic function, single dispatch.

Цель этого треда была немного развлечь меня в этот грусный понедельник. Я поэтому не стал особо заморачиваться изучением вопроса :)

А это хотя бы теоретически возможно?

Не знаю, но более безопасными они могут быть. В конце концов, статическая типизация тоже не избавляет от всех проблем.

Совместимость с древними версиями, в которых ничего про generics не было. Хотя, стирание получилось интересное, не все стирается.

В первых документах о Java Generics еще во времена jdk 1.4 были какие-то доводы. Уже не помню точно, но по-моему, главный из них - совместимость на уровня байт-кода. А сейчас, наверное, уже слишком поздно метаться. Терпрайз как никак. Тут, Биореактор лучше объяснит, что в немаргинальном язычке такого счастья перемен не надо.

Еще думаю, что придется сильно менять тогда Scala, поскольку очень многие финты ушами на уровне типов в Scala в своей реализации полагаются именно на type erasure. То есть, существуют и положительные стороны от этого нехорошего явления. Ораклу, конечно, дела до Scala большого нет, но все же. Так замечание.

У меня здесь в комментариях такое:

http://stackoverflow.com/questions/18684633/why-is-type-erasure-concept-being...

Биореактор лучше объяснит

к щясьтью, я его игнорирую :/

Я как раз из-за скалы и спросил. Потому что в ее случае от того, что паттерн-матчить nested generics не получается, иногда не очень удобно.

Некоторым хочется безопасные динамические языки... Мне, например :)

Вот и занялся бы Python, вместо др^Wизобретения очередного недоязычка ;)

В принципе все верно, только совместимость в jvm не только обратная, но и... как сказать-то, прямая. Т.е. можно использовать новые на момент выхода 1.5 средства языка и JDK, а гонять код на 1.4, если обновление платформы невозможно. А оно так частенько бывает, если мы про jvm внутри oracle или что-то подобное.

Сейчас всё это кажется устаревшим. Особенно с учетом развития scala, в которой, кстати, на обратную совместимость местами сознательно забили.

Игрушечный язык - игрушечные фичи.

Если бы они сохранили там ущербные коллекции из < 2.8, было бы хуже. Писатели на скале все молоды и неустанно трудолюбивы - им не трудно %)

Со всем согласен, Гвидо таки не просто тролль.

Осталось дождаться внедрения @multidispatch, и тогда питоном уже можно будет начать пользоваться :)

wat?

Потому что нарушает принципы duck typing. Тебя не должно волновать что за объект тебе передают. Это в теории.

т.е. это плохо?

x.is_a? Fixnum || fail(ArgumentError, 'Not a Fixnum')

т.е. это плохо?
x.is_a?

Вообще, да. Но для динамического языка такие конструкции неизбежны.

Расскажите мне, что плохого в assert?

Я не понял, почему проверка типа в рантайме является антипаттерном, кстати

Видимо, имеется в виду явная проверка. Потому что она вынуждает писать кучу повторяющегося boilerplate-кода в каждой обобщённой функции.

Не думаю, что это настолько сложно — сделать себе личный неспецифицированный и медленный кусочек CLOS, — но в качестве меры противодействия Lisp curse их решили стандартизировать.

Насчет говножавки не знаю, а так - man parametric polymorphism. Как только появляется возможность достать тип из полиморфного значения (а значит, варьировать поведение функции в зависимости от типа) в окно вылетают все free theorems.

чтобы для разных типов вызывать разные методы

В каком смысле? Разным типам естественно нужна разная обработка.

А в питонах не нужно, потому что утиная типизация.

Сейчас учу этот ваш питон(основной язык - C#). Значительная часть ошибок - несоответсвие типов, передаваемых в виде аргументов. В нормальном языке такое отсеивается ещё на этапе компиляции.

Посмотри на erlang.

Оно обусловлено тем, что генериков изначально не было, так что сделать их без erasure было нельзя, не переделывая существенно рантайм. По-этому вместо нормальных генериков (как в том же шарпе) сделали кривой костыль.

Мне просто стало интересно, почему в самом начале решели это сделать.

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

В скале наоборот из-за type erasure проблемы. Ну то есть да, Scala полагается на type erasure в том смысле, что в некоторых местах из-за этого самого type erasure приходится городить кривые костыли, которых без затирания типов городить было бы не нужно.

А вообще, type erasure - объективное зло, которое не имеет никаких преимуществ, зато имеет кучу недостатков. И наличиствует он в языках только по одной причине - уебищность рантайма.

Как только появляется возможность достать тип из полиморфного значения (а значит, варьировать поведение функции в зависимости от типа) в окно вылетают все free theorems.

Ничего не вылетает, не надо придумывать.

функции с несколькими аргументами тупо не нужны, а если у вас с этим проблемы go читать про каррирование.

Шутка, там не так написано.

а зря

Вот и занялся бы Python

Не интересно :(. Кстати, где-то я видел какой-то статистический линтер для питона. Увы, забыл название, пока ссылку найти не могу.

т.е. это плохо?

Понятие плохости субъективно. Одни говорят что плохо, другие говорят что хорошо.

Я считаю что опциональная проверка через аннотации типов это хорошо. Т.е., для продакшена можно отключить и немного сэкономить ресурсов, а для разрабов почему бы и не сделать. Впрочем, даже в продакшене не стал бы отключать если это не приносит ощутимого и нужного прироста производительности.

Посмотри на erlang.

Эрланг сила, не спорю. Особенно с mnesia. Увы, всё никак руки не доходят пощупать. Но если хотя бы 50% того что о ней пишут правда то это конфетка.

Scala для .NET отличается не в последнюю очередь из-за отсутствия там type erasure и другой модели generics. Не утверждаю, но предполагаю, что такие вещи, как higher kinded types и variance в Scala, эксплуатируют type erasure.

Ну, мнезия, конечно спорный момент. А в остальном да, он хорош. Кстати, на нем можно начинать писать уже через 3 дня;)

Не утверждаю, но предполагаю, что такие вещи, как higher kinded types и variance в Scala, эксплуатируют type erasure.

type erasure нельзя эксплуатировать. Потому что type erasure - это просто отсутствие точных типов в рантайме. Понятно, что все, что делается c type erasure, без затирания делается точно так же, тут полная обратная совместимость. А вот противоположное утверждение уже не верно.

Еще надо отметить, что полноценный параметрический полиморфизм не может существовать с type erasure.