И что же здесь противоречит закону? Эти соглашения в первую очередь через юристов проходят, всё там по закону, ни одной компании в мире не выгодно терять деньги в суде из-за соглашения. Персональные данные собирать можно, согласие прописано.
Вы не покупаете игру. Вы покупаете разрешение на запуск, использование файлов игры по соглашению. И, между прочим, не всегда изменение игры (моды) разрешено соглашением.
Не может "вечно" означать что угодно. Ну нельзя написать "навсегда * до завтра". При таких звёздочках можно писать условия этого "навсегда", как, например, делают банки - бесплатно при доходе Х и более на нашу карту. Здесь же буквально нету этой самой возможности иметь вечно, ни при каких условиях, судя по всему.
Что удивительно, когда их Liberica была доступна в России, скачивалось без проблем в виде регистрации. А так, хоть и сайт заблокирован для России, с гитхаба можно скачать.
Три варианта сравнения я имел в виду эти: ==, === и сам equals, можно еще и Objects.equals добавить. Каша получается особенно из-за того, что == и === имеет координально другой смысл от общепринятых. == устоканилось как проверка ссылки, === в популярных языках вообще проверяет идентичность типов + equals.
Если знать про ЯП чуть больше, то окажется, что в Java с equality "отсебятины" как бы не больше
А какая разница? Я сравниваю котлин с джавой (и рассуждаю, почему один удобнее другого), для меня джава - основа, которую пытается улучшить котлин, но не без косяков, к сожалению.
"тот самый вопрос" в топе по просмотрам сколько я себя помню. И каждый год туда таки что-то да дописывают :-)
Во-первых, это нормально для такого популярного языка, во-вторых, у Котлина точно так же хрен догадаешься, что есть ===. Да и пост этот закрыт для редактирования, не могут там ничего дополнять каждый год
"усложняет", вы хотели сказать. Потому и тряска, что вещи, которые можно было не трогать, сделаны СЛОЖНЕЕ, чем в Джаве. Что идет в разрез с позицией языка.
В моей практике наследование чаще вызывает проблемы чем решает их.
Вот в моей практике почти все на наследовании. И не удивительно, ведь Джава давно уже синоним ООП. Наследование - уже готовая система, которая имеет важные характеристики по умолчанию. Композиция же это просто переменная в классе, это костыль.
Т.е. ваше удобство важнее чем правильно работающая программа.
Она может правильно работать в обоих случаях. И неправильно тоже, представьте себе) А вообще - кто любит программы без багов? Как получать деньги за поддержку, если она прекрасно работает? (шутка)
Это как ругать машины BMW за то, что у них на логотипе есть синий цвет, а вы как раз не любите синий.
Так для меня это будет минусом при выборе машины, очевидно.
Я же не навязываю вам свое мнение, я лишь рассказал о том, какие моменты меня выбесили при работе с языком. Для меня это минусы, для кого-то наоборот плюсы, вы уж сами решайте, но меня перевоспитывать не надо, пожалуйста. Не всё, что удобно вам, удобно другим, и это абсолютно нормально
Если вы копнете глубже в рефлексию и возможности, которые предоставляют Kotlin типы и классы, то поймете почему они решили сделать свои варианты классов
Мне без разницы почему так вышло, есть финальный результат этого решения - моё неудобство. И я лишь говорю об этом. Я не говорю, что это неправильно или так делать нельзя, просто говорю, что для меня это минус.
Что ж, ваше право. Соболезную людям, которые пользуются софтом, к которому вы приложили руку. Тестирование тоже считаете бесполезной тратой времени?
А пользователь тут при чем? Он получит работающий код что в композиции, что в наследовании, например. Вы, судя по всему, из тех, кто работает ради работы? Быстро сдуетесь, если не получите удовольствие от работы.
Наследование полезно в единичных случаях, а не на постоянке. Вообще наследование как один большой костыль выглядит.
Наследование то костыль?) Сходите в дурку, пожалуйста, на обследование
Вы исходите из позиции "это точно плохо и не нужно привыкать к плохому", но у вас нет аргументов в пользу утверждения того что это плохо.
Я сказал, что это неудобно, а не плохо
Если вы печатаете одной рукой, то я могу вас понять. Иначе - звучит как придирка из воздуха. Программист - это не мартышка, которая ценится за максимальное количество нажатий клавиш в единицу времени.
Программист - кто постоянно жмет кнопки клавиатуры, и без этого миллион нажатий надо делать. Для чего еще больше? А вот просто так... Суть то не в том, что это мелочь, так и есть, но ради непонятно чего сделали СЛОЖНЕЕ, хотя язык стремится сделать проще. Парадокс. Потому я не люблю котлин, язык контрастов.
Путаницу как раз ввела java в свое время сделав оператор == практически бесполезным в большинстве случаев. В kotlin исправили эту проблему и большое им спасибо за это. Если сравнение ссылок кому-то действительно нужно, то это обычно продвинутые разработчики, которые в состоянии выбрать подходящий оператор в нужном месте.
Путаницы в Джаве нет, потому что Джава для Котлина как основа, не наоборот. А в Котлине поменяли смысл целого оператора на противоположный, что само по себе глупо. Так еще и третий добавили, при всем при том, что оригинальные методы от Джавы тоже работают. В результате имеем несколько вариантов сравнения, которые повторяют смысл друг друга, один из них имеет противоположный смысл с "материнским" языком, а третий имеет другой смысл в сравнении с другими языками в целом (=== всегда проверял не ссылку, а идентичность типов + equals).
Если здесь проблема в количестве символов, то странно слышать такие аргументы при сравнении с java, которая не славится краткостью
Так вы сами и подтверждаете по сути еще один парадокс, когда в языке ждя краткости сделано не кратко.
Наговнокодить можно и в java. В чем здесь вина kotlin?
Вот только котлин позиционируется как быстрота и сокращение, но когда каждая строчка по смыслу значит 10 таких строчек - сокращения начинают давать неприятный эффект. А в чем тогда смысл этих сокращений, если не использовать их?
что лучше - чуть меньшее время разработчика (что спорно т.к. куда больше время тратится потом на отлов и фикс багов) или безошибочная работа программы
Лучше или нет - совсем другой вопрос. Я говорил об удобстве для себя, потому что я программирую не ради идеальной программы, а ради удовольствия. Эта возня вызывает лишь негативные эмоции.
Откройте для себя композицию
Она рушит весь принцип ООП и полезна в единичных случаях, а не на постоянке. Вообще композиция как один большой костыль выглядит.
Да, на первых порах ооочень непривычно, но спустя некоторое время это воспринимается так же естественно как и в java.
Привыкнуть и не замечать можно и запах канализации в подъезде, привычка не доказывает ничего.
Почему нажатие шифт в этом кейсе проблема
Потому что язык стремится облегчить работу разработчика, но делает в этом случае ровно наоборот (на один клик больше каждый раз), причем я не могу представить ни одну вескую причину для подобного издевательства.
В том же C# '==' вызывает equals под капотом как и в Kotlin
Это всё создает огромную путаницу, особенно в контексте нескольких языков. Теперь в Котлине есть и ==, и === и equals и Objects.equals. Причем Java и Kotlin довольно близкие языки, но по-глупому разнятся иногда. Просто взять и поменять местами смысл одного из самых частых операторов - немыслимо, особенно учитывая то, что часто можно видеть комбинированные проекты либо в процессе перехода на Котлин.
А в каких сценариях это неудобство проявляется?
MyClass::class.java
Сразу видно, язык делает проще и удобнее, правда? Нет...
И что же здесь противоречит закону? Эти соглашения в первую очередь через юристов проходят, всё там по закону, ни одной компании в мире не выгодно терять деньги в суде из-за соглашения. Персональные данные собирать можно, согласие прописано.
Вы не покупаете игру. Вы покупаете разрешение на запуск, использование файлов игры по соглашению. И, между прочим, не всегда изменение игры (моды) разрешено соглашением.
А какое отношение к нам имеет английский суд и английский термин?
Не может "вечно" означать что угодно. Ну нельзя написать "навсегда * до завтра". При таких звёздочках можно писать условия этого "навсегда", как, например, делают банки - бесплатно при доходе Х и более на нашу карту. Здесь же буквально нету этой самой возможности иметь вечно, ни при каких условиях, судя по всему.
Мэилру давно владеет вк, а недавно и основная компания мэилру стала называться вк. Логично, что у них авторизация через вк
Сертификация для РФ (может быть важно компаниям и органам), патчи безопасности локального масштаба (в рамках страны)
Что удивительно, когда их Liberica была доступна в России, скачивалось без проблем в виде регистрации. А так, хоть и сайт заблокирован для России, с гитхаба можно скачать.
Ну так чтобы скачали те, у кого нету приложения
Через БД можно кому угодно выставить максимальный тариф, там до 10 человек будет
В Outline же есть авторизация через почту по ссылке из письма...
Коми, Ростелеком: -e 2 -f 1 --reverse-frag
сейчас проверил - абсолютно одинаково загружаются
Не знаю, что у вас тормозит, все быстро открывается и тормоза бывают не сильнее, чем на озоне
Три варианта сравнения я имел в виду эти: ==, === и сам equals, можно еще и Objects.equals добавить. Каша получается особенно из-за того, что == и === имеет координально другой смысл от общепринятых. == устоканилось как проверка ссылки, === в популярных языках вообще проверяет идентичность типов + equals.
А какая разница? Я сравниваю котлин с джавой (и рассуждаю, почему один удобнее другого), для меня джава - основа, которую пытается улучшить котлин, но не без косяков, к сожалению.
Во-первых, это нормально для такого популярного языка, во-вторых, у Котлина точно так же хрен догадаешься, что есть ===. Да и пост этот закрыт для редактирования, не могут там ничего дополнять каждый год
"усложняет", вы хотели сказать. Потому и тряска, что вещи, которые можно было не трогать, сделаны СЛОЖНЕЕ, чем в Джаве. Что идет в разрез с позицией языка.
Вот в моей практике почти все на наследовании. И не удивительно, ведь Джава давно уже синоним ООП. Наследование - уже готовая система, которая имеет важные характеристики по умолчанию. Композиция же это просто переменная в классе, это костыль.
Она может правильно работать в обоих случаях. И неправильно тоже, представьте себе)
А вообще - кто любит программы без багов? Как получать деньги за поддержку, если она прекрасно работает? (шутка)
В чей спор я влез? Это изначально МОЙ комментарий и У МЕНЯ спросили, какие вещи МНЕ неприятны в языке
Так для меня это будет минусом при выборе машины, очевидно.
Я же не навязываю вам свое мнение, я лишь рассказал о том, какие моменты меня выбесили при работе с языком. Для меня это минусы, для кого-то наоборот плюсы, вы уж сами решайте, но меня перевоспитывать не надо, пожалуйста. Не всё, что удобно вам, удобно другим, и это абсолютно нормально
Мне без разницы почему так вышло, есть финальный результат этого решения - моё неудобство. И я лишь говорю об этом. Я не говорю, что это неправильно или так делать нельзя, просто говорю, что для меня это минус.
А пользователь тут при чем? Он получит работающий код что в композиции, что в наследовании, например. Вы, судя по всему, из тех, кто работает ради работы? Быстро сдуетесь, если не получите удовольствие от работы.
Наследование то костыль?) Сходите в дурку, пожалуйста, на обследование
Я сказал, что это неудобно, а не плохо
Программист - кто постоянно жмет кнопки клавиатуры, и без этого миллион нажатий надо делать. Для чего еще больше? А вот просто так... Суть то не в том, что это мелочь, так и есть, но ради непонятно чего сделали СЛОЖНЕЕ, хотя язык стремится сделать проще. Парадокс. Потому я не люблю котлин, язык контрастов.
Путаницы в Джаве нет, потому что Джава для Котлина как основа, не наоборот. А в Котлине поменяли смысл целого оператора на противоположный, что само по себе глупо. Так еще и третий добавили, при всем при том, что оригинальные методы от Джавы тоже работают. В результате имеем несколько вариантов сравнения, которые повторяют смысл друг друга, один из них имеет противоположный смысл с "материнским" языком, а третий имеет другой смысл в сравнении с другими языками в целом (=== всегда проверял не ссылку, а идентичность типов + equals).
Так вы сами и подтверждаете по сути еще один парадокс, когда в языке ждя краткости сделано не кратко.
Привыкнуть ко всему можно, вопрос не в привычке, а УДОБНО ЛИ. Ответ нет.
Вот только котлин позиционируется как быстрота и сокращение, но когда каждая строчка по смыслу значит 10 таких строчек - сокращения начинают давать неприятный эффект. А в чем тогда смысл этих сокращений, если не использовать их?
Лучше или нет - совсем другой вопрос. Я говорил об удобстве для себя, потому что я программирую не ради идеальной программы, а ради удовольствия. Эта возня вызывает лишь негативные эмоции.
Она рушит весь принцип ООП и полезна в единичных случаях, а не на постоянке. Вообще композиция как один большой костыль выглядит.
Привыкнуть и не замечать можно и запах канализации в подъезде, привычка не доказывает ничего.
Потому что язык стремится облегчить работу разработчика, но делает в этом случае ровно наоборот (на один клик больше каждый раз), причем я не могу представить ни одну вескую причину для подобного издевательства.
Это всё создает огромную путаницу, особенно в контексте нескольких языков. Теперь в Котлине есть и ==, и === и equals и Objects.equals. Причем Java и Kotlin довольно близкие языки, но по-глупому разнятся иногда. Просто взять и поменять местами смысл одного из самых частых операторов - немыслимо, особенно учитывая то, что часто можно видеть комбинированные проекты либо в процессе перехода на Котлин.
Сразу видно, язык делает проще и удобнее, правда? Нет...