Так именно поэтому как раз и нет. Что есть ломбоки, котлины и другие средства борьбы с этим явлением. Не языкового уровня.
Ну, котлин это как раз языковой уровень. А ломбоки не все себе могут позволить(мы не можем, опять же — по техническим причинам). К тому же я сильно сомневаюсь что в оракл сидят и думают «ну есть же ломбок — пускай все им пользуются».
Ну я бы не так сказал. Я бы сказал, что это множество инженеров разной квалификации. То есть я высказываю свое мнение, что мне эта фича не нужна — потому что я решаю эти проблемы много лет, успешно, и другими способами.
Квалификация везде разная, я говорю об обобщенной картине в enterprise разработке. И, к сожалению, она показывает, что многие разработчики с трудом воспринимают что-то новое. Тот же ломбок многие не любят (деды NPE ловили и нам велели).
Ну вот видите как замечательно. А нам не нужны — но мы не можем использовать Java 9 по техническим причинам тоже. То есть, для нас они что есть, что их нет — ничего не меняется вообще.
Есть мнение, что все эти технические причины как-раз и вызваны застоем в развитии платформы и языка. Т.е. многие разработчики просто завязались на восьмой версии(в нашем случае разработчики обфускатора).
Может оракл внедрить Null-safety в Java 8? Очевидно нет. Поэтому мы (коих полно) и используем другие способы.
>На мой взгляд — нет.
>Нет, не потому, что не нужна.
Железная аргументация, конечно. Но факты показывают обратное — всякие ламбоки котлины и прочее не на ровном месте появились. Эти фичи давно себя показали с положительной стороны, и тут не надо угадывать. Null-safety в Java нужна, очень нужна. Даже необходима.
Многие говорят: но ведь люди живут же как-то? Как-то живут, но тут надо понимать что Java сообщество это множество инженеров старой закалки. И для них писать код — это тяжелая работа, и она должна оставаться тяжелой. Для них нормально писать по 2 дня то, что коллеги на пыхе делают за 2 часа. То, что в других языках автоматизируют — в java предпочитают натренировывать. Язык не позволяет автоматизировать бойлерплейт? Хорошо, мы просто будем везде его писать. А потом заставим IDE его генерировать. И это растёт как снежный ком.
А те части, которые всё таки можно хоть как-то автоматизировать — делают через рефлексию. В итоге получаются простыни хрупкого кода, который сыпется при рефакторинге.
в Java 9 и модули. И мы видим то, что мы видим — Java 8 все еще везде и всюду, а модули многим проектам просто ничего не дают.
В нашем проекте модули прям нужны, но мы не можем использовать Java 9 по техническим причинам.
>и ради этого синтаксического сахара UB теперь прет изо всех щелей.
Что-то не помню других языков, у которых количество UB увеличивается пропорционально количеству сахара.
Заучили баз ворды и теперь повторяете их как попугай
«TyDD», «Type class», какие ещё были «баз ворды»?
Тратить на вас время бессмысленно
Правильно, время лучше не тратить, а использовать. Например, для улучшения собственных навыков и знаний.
Все равно не поймете.
Согласен, мне действительно не понять почему hs List это ООП объект, и с чего вдруг ООП «намертво связанно в TyDD». Видимо, тут нужен Lead 80го уровня =)
инкапсуялиция она про собирать вместе, включать в себя а сокрытие про то что с наружи не видно
Инкапсуляция это когда внутреннее устройство компонента отделено от его интерфейса. (Компонент выступает в роли черного ящика).
Так List в хаскеле ничего не инкапсулирует, вся его структура доступна любому желающему.
Речь о том, что при появлении (мутабильного)состояния, придётся менять сигнатуру функции отправки сообщения.
Лист в хаскеле всё-таки больше управляющая конструкция, чем коллекция данных.
Возможно. Тем не менее, реализовать ООП в ФП языках(например hs) можно(как пример та же обёртка для гтк). Не факт, конечно, что это будет удобно использовать.
К тому же всегда будет проблема с несовместимостью разных объектных систем(за неимением встроенной в язык). Оно и понятно — язык то не объектно ориентированный.
А в названии TyDD как раз есть слово «тип». А всё что можно назвать «объектом» — это ООП.
Так уфологи, видимо, были основоположниками ООП, ведь они исследовали НЛО. Вот, нашли применение этим объектам в программировании.
Следующим шагом предлагаю провозгласить любую программу не только объектно ориентированной, но и функциональной(ФП), ведь в любой программе, определённо есть функции.
Да если Вы любой практически современный язык используете, Вы уже с типами так или иначе работаете. В js есть типы — значит js идёт рука об руку с TyDD, так? Правда проверить статически не получится, и TyDD не работает, но программа то базируется на свойствах каких-то типов… где логика?
ООП вообще никакого отношения к TyDD не имеет.
круто, наверное, много уметь. Видимо, настолько расширенные взгляды позволяют Вам утверждать что
ООП рука об руку идет с TyDD
Хотя казалось бы — какая связь? Ведь ООП это вообще не про статическую типизацию. И вполне нормально себя чувствует и в динамически типизированных языках.
Но куда нам, простым смертным. Видимо, остаётся поверить на слово.
Да в Scala у него могут появится методы от тайпклассов
implicit class, не type class
Грубо говоря в той же Java можно сказать что Методы это процедуры которые первым параметром принимают сам объект как this
зато у методов в Java есть исключительное право на доступ к приватным полям. Да и вообще — методы в Java это лишь отражение системы сообщений прежних языков, в которых развивалось ООП. И, конечно, метод в Java это не то же самое что обычная процедура.(да, я не сомневаюсь что Вы знаете про виртуальность, но по моему это очень важное отличие, которое позволяет изменить поведение объекта).
Вам просто надо перестать смотреть на объекты как на классы из Java
Я уже объяснял, и не раз, что такое объект ООП на мой взгляд. Когда я говорю о Java я специально помечаю что речь об объекте в терминологии Java, а не об объекте ООП.
более общая абстракция которая по сути значит инстансы неких типов данных
Нет не значит, по крайнем мере в ООП. Объект это не просто струтура данных, объект имеет собственное поведение, которое зависит от состояния, инкапсулируемого объектом.
да, любую структуру данных можно представить как объект. И обратное тоже верно. Можно любую структуру данных рассматривать как просто данные для вашей функции. 1 это и объект тип Int и одновременно не объект. Все зависит от того на основе какого предположения вы будете проектировать и писать свой код.
если речь том, что одну и ту же сущность можно представить в виде объекта, или не объекта — я с этим согласен. Беда в том, что по вашему определению это в любом случае будет объект. И никакой ценности представление в том или инном виде не имеет.
Теперь разницу поняли?
Конечно, сенсей. Не понял только, что общего State a имеет с ООП. По моему самое логичное объяснение «Если из всех инструментов у тебя есть только молоток, то в каждой проблеме ты увидишь гвоздь». Т.е. Вы просто не воспринимаете других подходов, ведь не знаете ничего кроме ООП.
Согласен(правда у меня есть собственное мнение насчёт сервисов и анемично модели, но это как-нибудь в другой раз), но на мой взгляд объект отличает как раз инкапсуляция и собственное поведение(в данном случае — делегирование сообщения другому объекту). А на Ваш взгляд экземпляр этого класса — объект с точки зрения ООП(не java)?
Это уже уход в философию, с призывами о расширении сознания. Я говорю об инженерном подходе, и с моей точки зрения Ваше определение термина объекта ООП не имеет практической ценности(как и отношения к ООП).
Я нигде не говорил что ФП мешает писать объектно-ориентированно. Не мешает, но и не помогает — это просто разные плоскости. На том же hs, как я уже говорил, вполне можно изобразить ООП(как и на С, для примера можно взять Gtk и его обёртку на hs).
Квалификация везде разная, я говорю об обобщенной картине в enterprise разработке. И, к сожалению, она показывает, что многие разработчики с трудом воспринимают что-то новое. Тот же ломбок многие не любят (деды NPE ловили и нам велели).
Есть мнение, что все эти технические причины как-раз и вызваны застоем в развитии платформы и языка. Т.е. многие разработчики просто завязались на восьмой версии(в нашем случае разработчики обфускатора).
Кому очевидно? Мне — нет.
>Нет, не потому, что не нужна.
Железная аргументация, конечно. Но факты показывают обратное — всякие ламбоки котлины и прочее не на ровном месте появились. Эти фичи давно себя показали с положительной стороны, и тут не надо угадывать. Null-safety в Java нужна, очень нужна. Даже необходима.
Многие говорят: но ведь люди живут же как-то? Как-то живут, но тут надо понимать что Java сообщество это множество инженеров старой закалки. И для них писать код — это тяжелая работа, и она должна оставаться тяжелой. Для них нормально писать по 2 дня то, что коллеги на пыхе делают за 2 часа. То, что в других языках автоматизируют — в java предпочитают натренировывать. Язык не позволяет автоматизировать бойлерплейт? Хорошо, мы просто будем везде его писать. А потом заставим IDE его генерировать. И это растёт как снежный ком.
А те части, которые всё таки можно хоть как-то автоматизировать — делают через рефлексию. В итоге получаются простыни хрупкого кода, который сыпется при рефакторинге.
В нашем проекте модули прям нужны, но мы не можем использовать Java 9 по техническим причинам.
Что-то не помню других языков, у которых количество UB увеличивается пропорционально количеству сахара.
Правильно, время лучше не тратить, а использовать. Например, для улучшения собственных навыков и знаний.
Согласен, мне действительно не понять почему hs List это ООП объект, и с чего вдруг ООП «намертво связанно в TyDD». Видимо, тут нужен Lead 80го уровня =)
Так List в хаскеле ничего не инкапсулирует, вся его структура доступна любому желающему.
Лист в хаскеле всё-таки больше управляющая конструкция, чем коллекция данных.
Я привык к другой трактовке термина "тип", но было бы интересно посмотреть и с альтернативной(для меня) точки зрения.
К тому же всегда будет проблема с несовместимостью разных объектных систем(за неимением встроенной в язык). Оно и понятно — язык то не объектно ориентированный.
А в названии TyDD как раз есть слово «тип». А всё что можно назвать «объектом» — это ООП.
Так уфологи, видимо, были основоположниками ООП, ведь они исследовали НЛО. Вот, нашли применение этим объектам в программировании.
Следующим шагом предлагаю провозгласить любую программу не только объектно ориентированной, но и функциональной(ФП), ведь в любой программе, определённо есть функции.
ООП вообще никакого отношения к TyDD не имеет.
Но куда нам, простым смертным. Видимо, остаётся поверить на слово.
зато у методов в Java есть исключительное право на доступ к приватным полям. Да и вообще — методы в Java это лишь отражение системы сообщений прежних языков, в которых развивалось ООП. И, конечно, метод в Java это не то же самое что обычная процедура.(да, я не сомневаюсь что Вы знаете про виртуальность, но по моему это очень важное отличие, которое позволяет изменить поведение объекта).
Нет не значит, по крайнем мере в ООП. Объект это не просто струтура данных, объект имеет собственное поведение, которое зависит от состояния, инкапсулируемого объектом.
если речь том, что одну и ту же сущность можно представить в виде объекта, или не объекта — я с этим согласен. Беда в том, что по вашему определению это в любом случае будет объект. И никакой ценности представление в том или инном виде не имеет.
Конечно, сенсей. Не понял только, что общего State a имеет с ООП. По моему самое логичное объяснение «Если из всех инструментов у тебя есть только молоток, то в каждой проблеме ты увидишь гвоздь». Т.е. Вы просто не воспринимаете других подходов, ведь не знаете ничего кроме ООП.