@kotlin_lang

Страница 319 из 982
Lev
13.09.2017
13:38:22
https://spring.io/blog/2016/03/04/core-container-refinements-in-spring-framework-4-3 да, не надо, если один констурктор... Я смотрю и @Service писать не надо.

Убрали Autowired а скоко эмоций

Руслан
13.09.2017
13:40:01
Ага, только @Service писать не нужно, только если ручками объявлять через @Bean)

Google
Lev
13.09.2017
13:43:27
На php есть такой (ненавистный мне) фреймворк - Zend. У него инъекция тупо автоматическая, без каких либо аннотаций и чего бы то ни было еще. То есть чтобы она не сработала или сработала не так как она хочет - надо приложить усилия. Я помню, как бесила меня автоматическая инъекция просто пипец как бесила и я гордо сидел на друго фреймворке - Symphony (почти полностью слизанном со Spring) и писал xml. И так нравилось. А ща - ниче, норм. Че писать очевидные вещи?

Руслан
13.09.2017
13:44:38
Удачи попасть в такой проект, или вернуться к нему хоть через месяц :)

Не говоря уже про инжект листов + подход, а давай-те будет автоматически все инжектить)

Евгений
13.09.2017
13:50:14
а что не так с автоинжектом?

Руслан
13.09.2017
13:51:03
> У него инъекция тупо автоматическая, без каких либо аннотаций и чего бы то ни было еще. Ну как сказать, все не так

Евгений
13.09.2017
13:52:06
я это к тому, что как бы открыт код, что Zend, что Spring, что Symfony - делай как тебе надо

Sergey
13.09.2017
13:52:29
а че не так с автовайрингом то? о_О

на той же Symfony к нему активно двигаются

для специфичных бинов есть же java config и вот еще kotlin dsl будет

Евгений
13.09.2017
13:53:16
автовайринг норм, есть конечно ситуации, особенно с инжектом коллекций (согласен) но жить можно

Nikita
13.09.2017
13:53:51
worker?.let { — очень странно. А если worker == null, просто ничего не делаем, как так и надо?
этот участок когда является методом, в которой при нормальной работе параметр worker не может быть null. Для удобства испольщую конструкцию let

Lev
13.09.2017
14:01:24
Я не понимаю как написать интерфейс для data class

Google
Lev
13.09.2017
14:02:01
как мне указать что интерфейс декларирует существование геттера свойства id ?

Lev
13.09.2017
14:03:14
А ну да.. val сеттера не будет...

Но тогда дочерний класс не сможет никак реализовать setId?

Quantum Harmonizer
13.09.2017
14:04:01
Mi
13.09.2017
14:04:22
ох уж эти наследуемые проперти

но вообще да

Lev
13.09.2017
14:06:01
А это нормально вообще делать свои классы для каких то значимых в логике, но простых вещей. Например.. ну не знаю. data class CompanyName { val name : String }

То есть можно было бы и строкой обойтись...

Quantum Harmonizer
13.09.2017
14:07:17
Я из соображений производительности делаю typealias'ы, но они не особо строгие.

Lev
13.09.2017
14:07:34
Что значит не особо строгие?

То есть в моем случае можно будет и просто строку передать в аргумент?

someMethod(name: CompanyName)

Quantum Harmonizer
13.09.2017
14:08:35
Что значит не особо строгие?
typealias Name = String val a: String = ... val b: Name = a

Lev
13.09.2017
14:08:47
а понятно

Quantum Harmonizer
13.09.2017
14:08:59
Lev
13.09.2017
14:09:19
kotlin native вообще рабочее?

Mi
13.09.2017
14:10:17
Преальфа

Или как-то так

Нет короче

Google
Mi
13.09.2017
14:10:33
Только для хардкорщиков

Lev
13.09.2017
14:29:42
Пытался сразу написать на интерфейсах, с value object, агрегатам, всем таким. Нифига не получается. Тупой

Как написать интерфейс для объектов-потребителей, в которых должен быть метод потребляющий только определенные обьекты-аргументы? При этом желательно принудить прогера писать объекты аргументы и в коде декларировать какой именно аргумент может быть потреблен? Тут явно с генериками, но я чет никак не допру

Можно ли вообще заставить прогера писать внутренний класс?

Fedor
13.09.2017
15:01:56
С днем программиста что ли

Lev
13.09.2017
15:04:33
class Consumer { fun consume(argument: ArgumentForThatConsumer) { } data class ArgumentForThatConsumer(//что внутри этого класса определяет сам прогер val field: String ) }

Lev
13.09.2017
15:06:00
Чтобы прогер писал класс аргумента для каждого своего класса

Я просто заранее не знаю что там будет за аргумент, для меня это будет просто Any

? animufag ?
13.09.2017
15:06:29
Interface Consumer<T> { fun consume(arument: T) }

Lev
13.09.2017
15:06:47
Ну так я чужой T заюзаю

? animufag ?
13.09.2017
15:07:10
что значит чужой

Lev
13.09.2017
15:07:40
От другого консьюмера

Quantum Harmonizer
13.09.2017
15:07:59
непонимат

? animufag ?
13.09.2017
15:08:13
да кажется это слишком сложная задача

Lev
13.09.2017
15:08:17
Сделает Вася консьюмера и аргумент. А потом Петя делает консьюмера, а аргумент ему лень делать и он берет петин аргумент

А ну хотя... отнаследуется и все...

Не прокатит

Да они блин... берут одни и теже аргументы, а потом изначальный автор ничерта поменять не может

Google
? animufag ?
13.09.2017
15:09:38
class VasyaConsumer: Consumer<PetyaArgument> { fun consume(argument: PetyaArgument){} }

Dmitry
13.09.2017
15:09:49
Да они блин... берут одни и теже аргументы, а потом изначальный автор ничерта поменять не может
Не только автор понять не может, какие аргументы, зачем берет, какое наследование. Что за поток сознания?

? animufag ?
13.09.2017
15:10:07
это уже давно продолжается

в слаке тоже забавно смотреть как люди пытаются в его агрегаты вникнуть

Lev
13.09.2017
15:11:22
Че, я на фрика похож со стороны?

? animufag ?
13.09.2017
15:11:32
да

Quantum Harmonizer
13.09.2017
15:12:04
Че, я на фрика похож со стороны?
мы тебя не видели, а вот изъясняешься непонятно

Mi
13.09.2017
15:14:03
class Consumer { fun<T: IArgument> consume(argument: T) { } data class ArgumentForThatConsumer : IArgument(//что внутри этого класса определяет сам прогер val field: String ) }

Так не поедет?

Lev
13.09.2017
15:16:06
Как это зачитит от того, что я взял агрумент соседа?

Mi
13.09.2017
15:16:33
Аргумент другого консьюмера?

Lev
13.09.2017
15:16:38
Да

Mi
13.09.2017
15:16:51
Параметризуй IArgument

? animufag ?
13.09.2017
15:16:53
так идея в том чтобы НЕЛЬЗЯ брать чужой аргумент?

Lev
13.09.2017
15:17:18
Да

? animufag ?
13.09.2017
15:17:26
ахах

Quantum Harmonizer
13.09.2017
15:17:29
разговор ни о чём

как это защитит от быдлокодера?

как это защитит от форматирования SSD?

? animufag ?
13.09.2017
15:17:52
ну просто не обобщай аргументы

Google
? animufag ?
13.09.2017
15:17:58
никаких интерфейсов

никаких дженериков

Mi
13.09.2017
15:18:07
class Consumer { fun<T: IArgument<Consumer>> consume(argument: T) { } data class ArgumentForThatConsumer : IArgument<Consumer>(//что внутри этого класса определяет сам прогер val field: String ) }

Lev
13.09.2017
15:18:15
Ну у "быдлокодеры" - это "дано". Не то чтобы я писал идеально...

? animufag ?
13.09.2017
15:18:17
просто пишешь консьюмер и просто аргумент и всё

код защищен

Lev
13.09.2017
15:18:23
Надо наоборот генерики строить

? animufag ?
13.09.2017
15:18:33
никто не сможет взять твой аргумент

Lev
13.09.2017
15:18:43
Да, точно, аргумент<консьюмер>

спсб

так стоп

Так там просто <Consumer>, а не какой то конкретный

Mi
13.09.2017
15:19:59
Я не понял что ты имеешь в виду

Quantum Harmonizer
13.09.2017
15:20:34
val notMyArg = Argmuent<Consumer1?) val myArg = notMyArg as Argument<Comsumer2>

Mi
13.09.2017
15:21:00
Каеф

Lev
13.09.2017
15:21:01
Так они 1 и 2 ставить не будут

? animufag ?
13.09.2017
15:21:16
Я не понял что ты имеешь в виду
он имеет ввиду что кто-то может реализовать аргумент для каконибудь консьюмера интерфейса и тогда получится переиспользуемый аргумент, чего нельзя допускать

Mi
13.09.2017
15:21:21
Они же быдлокодеры

Будут

Lev
13.09.2017
15:21:48
Надо просто написать final аргумент обертку... и в нем программно проверять

Страница 319 из 982