Так-то он испытал сильное влияние.

Да, с такой тенденцией через какое-то время пхп станет джавой и в уютный мирок жвм хлвнут... хотя хочется думать о чем-то хорошем

уже были попытки завернуть пхп на жвм. фейсбук даже свою виртуальную машину писал(hackvm и hacklang)

Я как бы намекаю на то, что PHP — это обёртка к Си, и парадигма программирования такая же.

Пхп уже очень давно не обертка над С

уже были попытки завернуть пхп на жвм. фейсбук даже свою виртуальную машину писал(hackvm и hacklang)

Что же у них в итоге не вышло интересно?

Зачем холи вар о языках в котлин группе?

Что же у них в итоге не вышло интересно?

в итоге выпустили новый движок(пхп7 ака phpng) и он работает шустрее чем поделки фейсбука

да, давайте завязывать)

в итоге выпустили новый движок(пхп7 ака phpng) и он работает шустрее чем поделки фейсбука

У них же был конвертер в Си?

У них же был конвертер в Си?

https://docs.hhvm.com/hhvm/FAQ/faq

Вот по этому мне нравится слак, создал там канал и общайся никому не мешает

#holywars

Развели тут pro.jvm

Стоит разрабатывать бэкенд с сложной бизнес логикой на котлине. Есть у кого опыт?

Может есть затыки в сравнении с джавой

Ну как раз для бизнес логики Котлин упрощает написание и чтение

Может есть затыки в сравнении с джавой

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

А если про фреймворкам смотреть?

Есть известные траблы?

Речь о спринге например

Или спарке

со спрингом все хорошо, а теперь можно даже добавить плагин для системы сборки, и с ним еще лучше

спарке это который апачи, или джава?

если джава, то я на нем писал еще до релиза, тоже без проблем

Джава спарк

мы с релиза сидим на котлин + спарк

каких-то специфичных проблем не замечали

http://talkingkotlin.com/spring-boot-with-sebastian-delueze/

Вообще специфичные проблемы конечно бывают, вроде спринговых, но они обычно или не критичные или решаются

Ребят, подскажите как подружить autowired и котлиновский object http://telegra.ph/object-autowired-02-14

никак, это ж статический класс

Да, все вроде бы логичо :) Я только начинаю осваивать spring, поэтому для меня не все прозрачно пока, поэтому надо перепроверять. Я не знаком еще с bean'ами и di которые тут в ходу. Моя основная специальность это android(java,kotlin) и ios(objectice-c, swift). Раньше desktop (С# wpf). А вот с backend миром только сейчас знакомлюсь, чтобы себе же писать нормальную API. Поэтому позвольте еще вопрос, как тогда завести @Autowired в классе, который не @RestController class Holder { @Autowired lateinit var objProjsRep: ProjsRep } Предполагаю нужна какая-то аннотация.

Spring 4.3+?

даже 5+

@Component class Holder(val objProjsRep: ProjsRep)

Тогда вот так лучше)

Блин, так не прокатит, так как я хотел вот так его заюзать object MyObj { fun projs(): List<Project> { val h = Holder() return h.objProjsRep.findAll() } }

object со спрингом не дружит (afaik)

т.е. ты Holder в контекст положишь, а object - нет

Окей, а как лучше тогда сделать. Этот MyObj, должен быть синглтоном на весь сервер. Как в спринге вы это делаете?

@Service/@Component

Они синглтоны

Спринг менеджит для тебя это

Окей, пойду целенаправленно почитаю тогда сначала про них, чтобы не задавать слишком простых вопросов

в спринге есть только один синглтон — это контекст приложения, всё остальное варится как бы внутри, даже само приложение работает как часть контекста, поэтому для доступа к определенным системам или сервисам используется di, т.е. обычно если одному объекту для жизни нужен другой, то он его просто принимает в конструктор, а подставить его при создании в конструктор ты доверяешь спрингу

это как конструктор, насоздавал элеметов и попросил спринг их раздать друг другу где надо

Ага, эту идею я уже уловил. Спасибо. Сейчас осталось освоить технические моменты.

в книге написано что можно делать такую структуру файлов для пакетов com: - package1.kt - package2.kt но идея возмущается на этот счет и требует переименовать пакет. приходится лепить что-то в духе com.package1.Package.kt com.package2.Package.kt

на сколько ок выключить испекцию в идее и делать как в первом варианте? или есть какие-то другие варианты?

файлы превратятся в классы, а не в пакеты

не совсем понимаю про пакеты

я хочу сделать файл, в котором будут функции для пакета

tree покажи

а зачем package1

просто com.example

тогда если я в package2 сделаю функцию test - будет коллизия

я хочу сделать файл, в котором будут функции для пакета

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

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

+1, просто сделай еще две папки(пакета)

а если и есть такая штука, думаю, лучше воздержаться от её использования, дабы не сбивать с толку тех, кто будет это потом смотреть

в книге написано что можно делать такую структуру файлов для пакетов com: - package1.kt - package2.kt но идея возмущается на этот счет и требует переименовать пакет. приходится лепить что-то в духе com.package1.Package.kt com.package2.Package.kt

А где в книге ?

плохой совет какой то))

А может, в таком случае, можно просто отключить предупреждение?

А может, в таком случае, можно просто отключить предупреждение?

можно важное что-то прошляпить. типа очечаток

можно важное что-то прошляпить. типа очечаток

А ты вообще планируешь использовать оба метода в одном файле? (Конфликт сигнатур все равно будет, если потом оба заимпортишь.)

import onePackage.something as oneSomething import anotherPackage.something as anotherSomething

Это хорошо, а если конфликтов большое (плюс имена новые придумывать)? Замучаешся ведь каждый раз так делать.

А ты вообще планируешь использовать оба метода в одном файле? (Конфликт сигнатур все равно будет, если потом оба заимпортишь.)

ну скажем у меня могут быть example.requests example.responses и там будут лежать одинаковые классы Credentials если без пакетов сделать, тогда будут конфликты

почему бы не использовать один класс Credentials?

ну скажем у меня могут быть example.requests example.responses и там будут лежать одинаковые классы Credentials если без пакетов сделать, тогда будут конфликты

Если у тебя еще и классы там лежат, то мне кажется ты быстро пройдешь лимит в 100/200 строк кода на файл и все равно придется раскидывать.

почему бы не использовать один класс Credentials?

я образно. например в responses credentials идет без пароля

Если у тебя еще и классы там лежат, то мне кажется ты быстро пройдешь лимит в 100/200 строк кода на файл и все равно придется раскидывать.

с дата классами задолбаешься в лимит входить

Те у тебя там только функции и data классы без логики (ФП пробуешь на Kotlin)?

дата классы с логикой могут приносить проблемы)

я образно. например в responses credentials идет без пароля

Надо с сериализатором правильно договариваться, а не классы плодить, ящитаю.

вспоминается анекдот: - Доктор, когда я вот вот так вот делаю у меня болит - А вы вот вот так вот не делайте

Надо с сериализатором правильно договариваться, а не классы плодить, ящитаю.

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

и коллеги успешно раздули его до 50 полей

Короче, большие классы — всегда плохо)

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

ну и плюс request/response это для api, сваггер хорошо его подхватывает и всегда наглядно какой нужен запрос и какой ответ

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

но язык-то позволяет?

котлин позволяет, да ?

это я про предложение сделать один класс вместо двух

вот я и хочу сделать dto.request{Credentials} dto.response{Credentials} при этом не плодить отдельные классы)

пока разделил все дата классы по отдельным

потому что вариант dto.request.Requests вообще не очень выглядит

вот я и хочу сделать dto.request{Credentials} dto.response{Credentials} при этом не плодить отдельные классы)

не очень понял

не очень понял

хочу файл-пакет, в котором сложу уютно дата классы

а кто мешает их положить просто в отдельные папки?

зачем обязательно в файл-пакет-то?

удобно ведь

ну как, сделать один класс, возможно немного удобнее, зато если будут еще появляться, то уже как-то не очень удобно

Кто-нибудь пробовал использовать jack с kotlin1.1 beta?