Утверждение "Клиент всегда прав" для частной школы ещё более применимо, чем для государственной. Руководство частной школы, помимо проверок, будет ещё бояться ухода ученика из школы, из-за чего школа будет получать меньше дохода. Так что в частной школе родитель ребенка имеет ещё больше власти, а положение педагога не меняется.
О, удачный код для обсуждения Котлина. myself в данной функции имеет тип Person?. Хотя скорее всего подразумевается, что Я уж точно существую. Как идеоматичнее быть в данном случае? Не хотелось бы использовать оператор !!, т.к. его использование расслабляет и плявляется соблазн использовать его повсеместно, что сводит на нет все плюсы котлина с точки зрения null безопасности. Можно написать ?: return, но это так же плохо как и пустой блок catch при обработке исключений. Наверное правильнее было бы бросить исключение: ?: throw IllegalStateException("Myself is not exists?!"), но не слишком ли много писанины ради ситуации, которая никогда должна случиться?
Кстати, если не менять код, то we будет иметь тип List<Person?>, что выглядит так же странно.
val handler = Handler()
val action = { println("Hello world!!!") }
handler.post(action)
handler.removeCallbacks(action)
handler.post(Runnable) добавляет Runnable в очередь на выполнение, а handler.removeCallbacks(Runnable) удаляет Runnable из этой очереди. Судя по коду, строка Hello world!!! не будет напечатана, но она печатается. В чем же дело?
Оказывается лямбда имеет тип Function0<Unit>, а handler.post(Runnable) и handler.removeCallbacks(Runnable) принимают в качестве аргумента Runnable, и котлин для удобства и бесшовной интегреции с Java оборачивает лямбду в Runnable и получается, что в очередь добавляется один Runnable, а удаляется другой.
Для того, что бы исправить ситуацию, нужно добавить Runnable перед лямбдой, вот так: val action = Runnable { println("Hello world!!!") }. Теперь action имеет тип Runnable и ничего не оборачивается и корректно работает.
Получается, что в данном случае проблема в том, что компилятор много на себя берет и скрывает часть своей работы от программиста с расчетом на то, что этот сахар ничего не сломает.
Любой сертификат использовать не получится, т.к. сертификат приложения используется для подписи запросов и только этой подписи доверяет сервер. Вытащить логику можно (можно даже в дебаге отследить момент расшифровки сертификата паролем и получить пароль в числом виде), проблема в том, что сертификаты меняются часто и прридется заново вытаскивать сертификат и пароль и перевыпускать свое приложение
Я не говорю об опасности такого подхода, это просто способ работы. Я говорю о том, что такой подход вряд ли будет сильно популярен у пользователей, да и вообще будет отрицательно сказываться на впечатлении о приложении.
Если бы мне встретилось приложение, которое бы запрашивало мои учетные данные от банка, то я бы вряд ли их ввел. Даже если бы мне автор дал ссылку на репозиторий, т.к. во-первых я не могу быть уверен, что приложение собрано именно из этих исходников (можно конечно самому собрать), а во-вторых разбираться в этих исходниках мало удовольствия и много времени
У меня есть опыт написания финансового приложения, в котором болшое внимание уделялось безопасности. И в нем для подтверждения оригинальности приложения использовался свой сертификат, но просто так его нельзя было бы так просто использовать в другом приложении, т.к. он был запаролен, а пароль был зашифрован и расшифровывался в приложении во время работы (да, его можно было вытащить, но это было бы не просто).
Правильно ли я понимаю, что при таком подходе пользователю необходимо будет вводить логин и пароль от своего банковского приложения в левое приложение? Вряд ли таких пользователей будет много, банки на каждом углу твердят о том, что нельзя вводить учетные данные где попало, к тому же скорее всего придется ещё подтверждать вход через СМС (если не все банки такое требуют то большинство), а в нем ещё раз написано, что не стоит вводить этот код не в официальное приложение
До того, как гугл заговорил о Котлине, на нем уже было писать куда комфортнее, чем на джаве. Если бы не заговорил, то все равно бы писали, но популярность росла бы медленнее
Только в JavaScript и то только потому, что JavaScript является подобием байткода для браузеров. Трансляция в другие языки, на мой взгляд, не нужна, т.к. если нужно использовать код, написанный на котлине, в компилируемом языке, то можно скомпилировать его в библиотеку. А если же есть потребность использования его в интерпретируемом языке, то значит к программе не предъявляются жесткие требования по производительности, и можно использовать микросервисную архитектуру. Или же так же как для компилируемых языков, использовать библиотеку
Неужели Вы были так привязаны к хостингу, который поддерживал только PHP, что были вынуждены разрабатывать собственный язык? Или это было всего лишь поводом?
Если хостинг с прибитым PHP был необходим, то не проще ли было написать свой конвертер PHP <-> JS, чем писать целый язык?
А если ограничение хостинга было всего лишь поводом, то подобное можно было бы реализовать, помимо предложенных решений (NodeJS, ...), на котлине, он и хорош как язык для бакенда, и транслируется в JavaScript.
Его синтаксис поддерживает те принципы, которые Вы описали в разделе "Принципы функционального программирования".
Асинхронность реализуется через корутины:
val user = getUser(name)
val postsCountAsync = async { getUserPostsCount(user.id) }
val commentsCountAsync = async { getUserCommentsCount(user.id) }
println("Постов: ${postsCountAsync.await()}, комментариев: ${commentsCountAsync.await()}")
В данном коде запросы количества постов и количества комментариев будут выполняться параллельно и асинхронно.
Неизменяемость структур данных реализуется через неизменяемые коллекции и неизменяемые переменные (val). Функции высших порядков присутствуют.
Цепочки вызовов можно реализовать схожим образом:
val user = User().apply {
setName('John')
addEmail("john@example.com")
}
В отличии от BAYRELL Language, для этой функциональности котлину не требуется специальный синтаксис, т.к. apply это всего лишь функция, которая принимает на вход лямбду.
Данный комментарий меня побудило написать ощущение того, что для описанных требований уже существует как минимум один язык (не считая отсутствия возможности трансляции его в PHP)
Утверждение "Клиент всегда прав" для частной школы ещё более применимо, чем для государственной. Руководство частной школы, помимо проверок, будет ещё бояться ухода ученика из школы, из-за чего школа будет получать меньше дохода. Так что в частной школе родитель ребенка имеет ещё больше власти, а положение педагога не меняется.
В Котлине статическая типизация.
varв Java иautoв C++ не делают же их динамически типизированными.А, про
firstя забыл. В данной ситуации, на мой взгляд, похоже лучше всего подходит.if/elseне сильно длиннее.О, удачный код для обсуждения Котлина.
myselfв данной функции имеет типPerson?. Хотя скорее всего подразумевается, что Я уж точно существую. Как идеоматичнее быть в данном случае? Не хотелось бы использовать оператор!!, т.к. его использование расслабляет и плявляется соблазн использовать его повсеместно, что сводит на нет все плюсы котлина с точки зрения null безопасности. Можно написать?: return, но это так же плохо как и пустой блокcatchпри обработке исключений. Наверное правильнее было бы бросить исключение:?: throw IllegalStateException("Myself is not exists?!"), но не слишком ли много писанины ради ситуации, которая никогда должна случиться?Кстати, если не менять код, то
weбудет иметь типList<Person?>, что выглядит так же странно.Однажды я писал примерно вот такой код:
handler.post(Runnable)добавляет Runnable в очередь на выполнение, аhandler.removeCallbacks(Runnable)удаляет Runnable из этой очереди. Судя по коду, строкаHello world!!!не будет напечатана, но она печатается. В чем же дело?Оказывается лямбда имеет тип
Function0<Unit>, аhandler.post(Runnable)иhandler.removeCallbacks(Runnable)принимают в качестве аргументаRunnable, и котлин для удобства и бесшовной интегреции с Java оборачивает лямбду вRunnableи получается, что в очередь добавляется одинRunnable, а удаляется другой.Для того, что бы исправить ситуацию, нужно добавить
Runnableперед лямбдой, вот так:val action = Runnable { println("Hello world!!!") }. Теперьactionимеет типRunnableи ничего не оборачивается и корректно работает.Получается, что в данном случае проблема в том, что компилятор много на себя берет и скрывает часть своей работы от программиста с расчетом на то, что этот сахар ничего не сломает.
Все уже придумано до нас https://habr.com/ru/company/yandex/blog/493950/
Сертификат то нужен не только для дебага, а и для использования. Север не даст использовать API без сертификата
Любой сертификат использовать не получится, т.к. сертификат приложения используется для подписи запросов и только этой подписи доверяет сервер. Вытащить логику можно (можно даже в дебаге отследить момент расшифровки сертификата паролем и получить пароль в числом виде), проблема в том, что сертификаты меняются часто и прридется заново вытаскивать сертификат и пароль и перевыпускать свое приложение
Я не говорю об опасности такого подхода, это просто способ работы. Я говорю о том, что такой подход вряд ли будет сильно популярен у пользователей, да и вообще будет отрицательно сказываться на впечатлении о приложении.
Если бы мне встретилось приложение, которое бы запрашивало мои учетные данные от банка, то я бы вряд ли их ввел. Даже если бы мне автор дал ссылку на репозиторий, т.к. во-первых я не могу быть уверен, что приложение собрано именно из этих исходников (можно конечно самому собрать), а во-вторых разбираться в этих исходниках мало удовольствия и много времени
У меня есть опыт написания финансового приложения, в котором болшое внимание уделялось безопасности. И в нем для подтверждения оригинальности приложения использовался свой сертификат, но просто так его нельзя было бы так просто использовать в другом приложении, т.к. он был запаролен, а пароль был зашифрован и расшифровывался в приложении во время работы (да, его можно было вытащить, но это было бы не просто).
Правильно ли я понимаю, что при таком подходе пользователю необходимо будет вводить логин и пароль от своего банковского приложения в левое приложение? Вряд ли таких пользователей будет много, банки на каждом углу твердят о том, что нельзя вводить учетные данные где попало, к тому же скорее всего придется ещё подтверждать вход через СМС (если не все банки такое требуют то большинство), а в нем ещё раз написано, что не стоит вводить этот код не в официальное приложение
До того, как гугл заговорил о Котлине, на нем уже было писать куда комфортнее, чем на джаве. Если бы не заговорил, то все равно бы писали, но популярность росла бы медленнее
Только в JavaScript и то только потому, что JavaScript является подобием байткода для браузеров. Трансляция в другие языки, на мой взгляд, не нужна, т.к. если нужно использовать код, написанный на котлине, в компилируемом языке, то можно скомпилировать его в библиотеку. А если же есть потребность использования его в интерпретируемом языке, то значит к программе не предъявляются жесткие требования по производительности, и можно использовать микросервисную архитектуру. Или же так же как для компилируемых языков, использовать библиотеку
Неужели Вы были так привязаны к хостингу, который поддерживал только PHP, что были вынуждены разрабатывать собственный язык? Или это было всего лишь поводом?
Если хостинг с прибитым PHP был необходим, то не проще ли было написать свой конвертер PHP <-> JS, чем писать целый язык?
А если ограничение хостинга было всего лишь поводом, то подобное можно было бы реализовать, помимо предложенных решений (NodeJS, ...), на котлине, он и хорош как язык для бакенда, и транслируется в JavaScript.
Его синтаксис поддерживает те принципы, которые Вы описали в разделе "Принципы функционального программирования".
Асинхронность реализуется через корутины:
В данном коде запросы количества постов и количества комментариев будут выполняться параллельно и асинхронно.
Неизменяемость структур данных реализуется через неизменяемые коллекции и неизменяемые переменные (val). Функции высших порядков присутствуют.
Цепочки вызовов можно реализовать схожим образом:
В отличии от BAYRELL Language, для этой функциональности котлину не требуется специальный синтаксис, т.к. apply это всего лишь функция, которая принимает на вход лямбду.
Данный комментарий меня побудило написать ощущение того, что для описанных требований уже существует как минимум один язык (не считая отсутствия возможности трансляции его в PHP)