- 1
- 2
- 3
- 4
status.setCounter(new Number(
Number.nullToZero(
status.getCounter()).add(
value.movePointRight(2))));-
Java / Говнокод #11346
+75
Действительно, кому нужна перегрузка операторов?
Запостил:
Zozopy,
03 Июля 2012
Follow us!
Если не абузить операторы, и использовать их только в очевидных случаях - арифметика, строки, операции над контейнерами, и возможно что-то еще, то особых проблем не вижу.
а джава по сравнению со скалой вообще УГ
В основном радует встроенная многопоточность и HotSpot. А так тоже фэйлов хватает.
И что это за "свой примитив"?
Дженерики -- это просто-напросто такая фича, которая позволяет не расставлять кастовки типов у классов, реализующих общий интерфейс доступа вне зависимости от данного.
Компилятор расставляет кастовки типа за программиста и следит, чтобы правильное в правильное превращалось. В runtime есть только минимальная память о дженериках. Хорошему программисту она не требуется.
По-сути, это механизм именно периода компиляции.
Не нужно выкрутасов:> по принципу лишь бы отвязались
Нет, чтобы обеспечить максимально возможную совместимость со старым кодом.
А на этапе компиляции будет проверена статическая совместимость параметров.
В 90% случаев крики о Generics от непонимания того, для чего вообще это нужно. Хорошие программисты всегда читают документацию, прежде, чем работать с чужим кодом.
Кроме того, вы говорите о языке Java. Здесь главный принцип "это вам не нужно". Если вы начинаете писать такой код, что вам не хватает гибкости -- не пишите его. Сделайте по-другому.
Или пишите на другом языке, более гибком.
Да что вы такое говорите. Не должны? Кому? Почему? От куда такая уверенность? При чем тут чужой код? Хорошие программисты читают документацию? - Ну наверное, а Волга тоже иногда впадает в Каспийское море... В Яве генерики сделаны плохо, а от того, что этот факт хорошо задокументирован лучше как-то не становиться.
Наверное глубокое копирование объектов и желание узнать родовой параметр - это через чур "гибко" для Явы, а не типичная инженерная задача, с которой программист так или иначе сталкивается в более-менее нетривиальном проекте, и наверное 100500 библиотек написаных на Яве, которые делают это самое глубокое копирование (и все - плохо, но это не важно, важен сам факт) явно указывают на то, что эта проблема никогда не возникает в программах написанных на Яве.
Спасибо, что порекомендовали мне другой лучший язык. Я бы сам не догадался, и продолжал бы мучаться, так и не подозревая о том, что есть и другие языки!
На приземлённом примере.
Покупаете вы mp3 плеер, который предназначен для прослушивания файлов со звуковым содержимым, а вы забиваете им гвозди. Он рассыпается.
Вы приходите в мастерскую и жалуетесь: "У вас mp3 плеер плохо сделан! Я не могу забить им гвозди!"
Каждый инструмент имеет определённое назначение, которое описано в документации к инструменту. Generics в Java имеют определённое назначение. Если вам нужно что-то другое, то и использовать нужно что-то другое. Это не значит, что mp3 плеер плохо сделан, он просто не предназначен для забивания гвоздей. Если часто возникает какая-то задача, а вас инструмент не удовлетворяет -- вы выбрали не тот инструмент.
Когда заявлено одно, а получается другое, своего рода "обман", это плохо -- "что-то плохо сделано", "не продумано" и т.д.
А то, что какая-то библиотека не оправдывает ваших личных ожиданий -- не делает её плохой. Неудобной для вас -- да. Но не плохой. То, для чего она означена, она делает прекрасно.
Если этот инструмент, делающий зависимое копирование, действительно нужен -- пишите в Oracle, может быть они услышат. Ведь и Generics появились в ответ на зов разработчиков, так как с абстрактными контейнерами можно было легко наделать ошибок.
И не надо ныть: "ой, плохо сделано", "ой, там всё неправильно". Там -- всё правильно! Разруха в головах.
В целом они решают те проблемы, которые призваны были решить - уменьшить количество ошибок, связанных с типами, и, как частный случай, предоставить пользователям API больше информации о том, что лежит в контейнерах. Сохранив при этом возможность передавать типизированные коллекции туда, где требуются нетипизированные и обратно.
То, что они не решают каких-то других, ваших проблем - это ваша проблема. С такими дженериками гораздо лучше, чем без них.
А компетентные / не компетентные, вон MXML придумал Eli Greenfield - человек с несколькими учеными степенями, главный инжинер Адоби по всему, что касается Флеша - и такое редкостное говно придумал, что любой студент-первокурсник лучше бы сделал. Ученая степень не гарантирует, что получится не-говно.
У меня нет проблем с Явой, т.как слава богу использовать ее почти не приходится. Проблема есть с идиотами, для которых Ява - это образец того, как нужно программировать и эталон терминологии в программировании, в то время как в ней в большинстве случаев все шиворот-навыворот.
Ну вот вы же сами смешиваете огурцы с помидорами, а потом возмущаетесь, что кто-то там тоже смешивает понятия.
Может быть термин неудачный, не знаю. Но тогда так говорите: "Generics -- очень неудачное название для параметризованных типов в Java".
Если вы действительно не понимаете разницу между C++ шаблонами и Java Generics, то в нескольких словах: "C++ шаблоны это мета-язык генерации новых типов", а Java Generics -- это механизм привидения параметризованных типов к абстрактным.
То есть, это вообще в разные стороны вектора направлены.
C++ Templates -- генерирует новые типы
Java Generics -- уничтожает типы
Точно так же, например, в FlashDevelop (редактор AS) можно ставить аннотации после объявления массивов, типа:
и редактор вам выдаст предупреждение если вы напишете array.push(100); но это исключительно фича редактора, а не языка / рантайма. Языком / рантаймом это не поддерживается. Точно таким же образом в Яве не поддерживаются родовые параметры функции или класса. Родовых переменных не существует в принципе (даже на уровне шаблонов). На какие-то выражения родовые параметры распространяются, а на какие-то нет (catch не может ловить ошибки не объедененные в один конкретный тип потому что catch (Object e) естественно не проходит.)
Это и есть убогая реализация, которая работает меньше чем на половину, которую, из практических соображений, лучше вообще избегать, т.как чревато всякими недоумениями, именно изза непоследовательности в реализации.
Generics выполняют определённую задачу, эту задачу они выполняют хорошо. Какие могут быть претензии к Generics?
У вас какая-то очень эгоистичная философия, самоцентричная. Раз мне не подходит, значит это плохо, значит это вообще не то, это плохо, этого не должно быть.
В очередной раз.
Вы говорите, что вам нужна информация о параметре Generic типа во время работы системы. Но параметризованные классы в Java созданы для таких задач, когда информация нужна чуть чаще, чем никогда. Значит вы выбрали не тот инструмент для вашей задачи.
Generics не стали хуже.
Мне с ними очень удобно. Я могу использовать контейнеры и не ставить кастовки руками. Если даже ошибусь -- компилятор предупредит. Мне этого достаточно для моих задач.
И я думаю, что многим этого хватает. А если вы работаете в такой специфической области, то может быть для ваших задач и язык есть не универсальный, а специфический?
Чего вы людям головы морочите?
Это уже какой-то флейм на Java идёт.
Яву преподают в учебных заведениях связанных с программированием, но типично забывают объяснить, что система типов в Яве очень упрощенная и не соответсвующая обычному представлению о том, что такое типы. К чему это приводит: растет количество программистов с искаженным мировосприятием, которые верят в то, что в Яве есть родовые параметры, (а с ними - параметризированые классы и функции), в то время, как их по-сути нет, а то, что предлагается вместо них - профанация и искажение идеи. Мало того, что они в это верят, они еще и пытаются навязать свою точку зрения другим. Достаточно почитать пожелания-улучшения других языков типа того же Яваскрипта - так от туда просто за версту несет.
Я не говорю как вам писать код и какие задачи решать, а говорю следующее: называйте вещи своими именами, нет в Яве родовых переменных / параметров и никогда не было. Есть шаблоны / аннотации, которые помогают предотвратить некоторые ошибки возникающие там, где в принципе хорошо было бы использовать родовые параметры / переменные. Удобно их использовать? - за неимением лучшего - вполне возможно. Помогает? - ну, раз ничего другого нет, то наверное же! Но это ж не значит, что именно так нужно делать.
Java - далеко не идеал, но в каждом практичном языке были и будут свои проблемы. Где-то на них будут натыкаться чаще, где-то реже (и в этих случаях, скорее всего, проблемы будут глубже и непонятней).
@wvxvw - особая разновидность тролля. Он ругает хаскеллы и эрланги, противопоставляя их "кошерным" java и JS, а в соседних тредах хаит JS и Java, как языки, лучше которых, видите ли, придумали бы даже школьники.
Разъяснения и дополнения к пирамиде языков глазами wvxvw
Но есть много языков, про которые я мало что знаю. Типа того же Паскаля или Перла.
Сцылку, пожалуйста. А вообще лучше просто было его процитировать.
Я-то понял что речь об этом:
http://govnokod.ru/10265
Но где он явно сказал о том что они "кошерны"?
>Пирамида языков глазами wvxvw:
Ты забыл про ЭкщонСкрипт.
это как теплое с мягким сравнивать
То что оно выглядит внешне как шаблоны С++ еще не означает что внутри оно тоже шаблоны С++. И ведь шаблоны С++ далеко не идеал. Именно из-за своей усложненности.
>> и вообще искажение изначальной идеи
Да. Это немного другая вещь. И потому название другое.
>>в Яве так, позаимствовано из С++ шаблонов
Да, отчасти. Ну и что? А С++ позаимствовал их из Ады - там такое издавна есть. Верно, Тарас?
>> С такими дженериками гораздо лучше, чем без них.
Однозначно. Лучше иметь плохой дом, чем вообще быть бомжом.
>>вы говорите о языке Java. Здесь главный принцип "это вам не нужно"
Лол, надо запомнить.
> CLU is a programming language created by Barbara Liskov
> Ada was named after Ada Lovelace
Есть особые случаи, например, Полиморфная Рекурсия , и я даже могу представить себе примеры её использования (гетерогенные списки, которые нужны чуть реже чем никогда). Но в реальной жизни такое встретить довольно сложно.
А если вам нужны глубокие копии - реализуйте Clonable и делайте clone() ручками, но, опять же, в реальной жизни это нужно довольно редко.
Пример использования: есть два jar'a в одном библиотечные классы, в другом какой-то код конкретного инстанса сервера. Обычно они компилируются вместе, но тут кто-то решил пропатчить библиотечный jar и залил его на сервер не интересуясь другими jar'ами, которые использовали его как ClassFromConcreteServer<LibraryClass>. Врезультате чего следующая загрузка конкретного инстанса проходит "успешно" - т.как Ява не будет искать родовой парамтер пока мы его конкретно не попросим, а т.как инстансы ClassFromConcreteServer<LibraryClass> на самом деле создаются как ClassFromConcreteServer<Object>, то мы об этой проблеме узнаем не скоро, а, как повезет, может через час, а может через пару дней, когда вдруг окажется что ClassFromConcreteServer<LibraryClass> нужно сериализовать для передачи куда-нибудь, а сериализовать не из чего.
>> если требуемых классов нет в classpath, то java тут не при чём, это ваш косяк
Если у вас неконсистентный classpath, последствия будут удручающими и всё может грохнуться в самый неожиданный момент. И дженерики тут не при чём, всё прекрасно грохнется и без них.
> ClassFromConcreteServer<LibraryClass>
Этот класс, очевидно, должен в себе содержать инстансы этого типа. Где есть инстансы, там есть классы, которые, очевидно, должны быть загружены.
Если дженерики не решают ваших проблем, это не значит, что они - говно. Это означает лишь то, что вы их неправильно используете.
Продолжать дискуссию не вижу смысла.
Я смысла не видел с самого начала, но проект иногда долго собирается.
И сразу фейл.
Вот "В танке нет гусениц, есть колеса которые пытаются решать проблемы гусениц" - схожее утверждение.
ява фигня мне не понравилось !!!!!!!!!!! остоётся токо ждать лутшего.Это для меня говно плохо зделана тупо.Немогли зделать всё как в крустах!!! И шаблоны и управление памятью.Не рекоминдую такую яву!!!
Про пхп и пасцаль хотелось бы умолчать.
Да, сишка - исключение. Это язык, в котором всё должно быть просто и влоб by design.
Scala: +, -, * - это обычные методы, 1 + 2 == 1.+(2). Для "перегрузки" достаточно просто определений вроде def +(x: Int): Int = ....
В Lisp всё немного сложнее: похоже, придётся определить свой дженериковый +, скрывающий + из стандартного пакета/нэймспейса. Но в целом операторы там также ничем не отличаются от обычных функций.
>Но в целом операторы там также ничем не отличаются от обычных функций.
Ключевая фраза. То есть на самом деле очередная killer-фича (перегрузка операторов) языку не нужна.
А нужно приведение всего к общему знаменателю, унификация и упрощение.
заплюсовываю. именно поэтому http://govnokod.ru/11346#comment145494
...и поэтому мне нравится JS. Именно его канонiчная редакция ECMAScript 1.6.
Ну а почти все фичи что дальше то ересь, ну может за исключением yieldов, генераторов-итераторов и пары других приятных моментов (хотя тоже спорно).
>мы тут уже выясняли, что JS мало кто любит :)
Это где вы посмели?!
Вот почитал тот тред и понял:
в javaScripte нету перегрузки операторов, но есть очень похожая по духу вещь - прототипы.
Это выносит мозг чуть более чем всем новичкам в JS.
Прототипы и перегрузку объединяет одно - они легко превращают код в пиздец.
Вот. Именно это самая вкусная его часть
Заплюсовываю тебя в ответ.
на самом деле что может быть красивее:
Они мудаки. Для меня это структурный и функциональный язык.
Где там вообще инкапсуляция, зачем гетеры, сеттеры? Непонятно.
Не знаю правильно ли это, но я люблю делать наследование через расширение одной структуры другой (с заменой).
А полиморфизм - это просто наличие метода с нужным именем.
можно пояснить мысль примером на JS?
PS. А вот резиг поясняет:
http://ejohn.org/blog/simple-javascript-inheritance/
http://base2.googlecode.com/svn/version/1.0.2/doc/base2.html#/doc/!base2.Map::extend
http://www.prototypejs.org/api/object/extend
http://api.jquery.com/jQuery.extend/
http://www.sencha.com/learn/ext-extend-explained1/
jQuery.extend(), Map.extend(), Ext.extend() - прям неписанный стандарт.
тут в основе либо прототипирование, либо делегирование.
а вообще подход jQuery в смысле обертывания стандартных объектов и уже последующей манипуляции с оберткой мне как-то настолько понравилась, что я сделал нечто такое на php
Ну в любом случае без либ - никуда.
>>подход jQuery в смысле обертывания стандартных объектов и уже последующей манипуляции с оберткой
Роман меня поправит, если я неправ, но это дело попахивает монадами (безотносительно чистых вычислений).
просто тут кто-то заявлял типа монады - нахуй они нужны, в js никто не пишет.
но как цепочка связанных вычислений, монады - вполне юзабельный паттерн.
Хз, может в Схеме по-другому.
Так тогда можно статик-методы комбинировать с методами классов
(и даже extension methods в C# и implicit в скале)
Кстати я только теперь начинаю сознательно улавливать мистическую связь между:
- перегрузкой операторов
- Prototype в js
- extension methods в C# и implicit в скале
и понимать почему это всё мне не нравится.
Все суть винегрет модели (абстрактная часть) и реализации (конкретная)?
другое дело:
К тому же `identifier` редактор может подсветить как оператор - будет читабельнее.
примерно так
Ну и код нормально форматировать.
Не думаю, что варарги хорошее решение для функций, которые, к примеру, могут попасть в цикл рисования тайлов.
> Ну и код нормально форматировать.
Ну в том коде еще не помешало бы нормально называть переменные. Ибо, зачастую, хрен поймешь, что означает какой-нибудь ols или nrg.
Чего так?
Нет уверенности, что компилятор и jit превратят код с ними во что-то шустрое и доброе.
Не пойму.
>умный компилятор сможет заинлайнить
А вот javac не умеет. Речь была об этом
>А вот с массивами у меня такой уверенности уже нет
Спасибо, я понял. Учту в будущем.
Но любителям немутабельных хацкилов грех на такое жаловаться.
Да собственно что там массив что там массив. Так что ничем.
Но в оригинальном коде то функции с двумя аргументами. Причем довольно простые. И, имхо, есть вероятность того, что они заинлайнятся, из их кишков будут выкинуты все new, и они просто превратятся в несколько арифметических операций. А вот с массивами у меня такой уверенности уже нет.