AN
А без jlink ещё можно?
Jlink нужен только для сборки самого jdk. Для своих либ не нужен
Size: a a a
2020 August 25
B
Блин, как раньше было просто с classpath, а сейчас голова пухнет...
AN
Блин, как раньше было просто с classpath, а сейчас голова пухнет...
А чего пухнет, jmod подключаются точно так же как jar. А тут даже плагин все для вас делает. Ошибка типичная в том, что народ свои приложения в jmod паковать пытается - вот этого делать не надо.
BP
Для использования openjfx не нужна модульная сборка, посмотрите примеры в https://github.com/beryx/badass-runtime-plugin. Или gradle-javafx-plugin
> Или gradle-javafx-plugin
там обе так то нужны
там обе так то нужны
RI
Блин, как раньше было просто с classpath, а сейчас голова пухнет...
BP
RI
AN
Хотелось бы всё одной командой из Gradle делать
Если вам просто надо javafx без рантайма, то просто берете openjfx плагин и все. Он кривой (я его своим заменил), но для простых случаев точно сгодится
AS
Добрый вечер. Подскажите пожалуйста насколько корректна с точки зрения общей практики такая конструкция
Есть некоторый параметризованный фабричный метод (передается "param0") который создает объект класса
Класс в свою очередь реализутет method chaining в виде методов setParamA(paramA: Int) и setParamB(paramB: Float).
В результате получается конструкция:
val obj = factory.createInstance("param0"). setParamA(1).setParam(2.0)
Есть некоторый параметризованный фабричный метод (передается "param0") который создает объект класса
Класс в свою очередь реализутет method chaining в виде методов setParamA(paramA: Int) и setParamB(paramB: Float).
В результате получается конструкция:
val obj = factory.createInstance("param0"). setParamA(1).setParam(2.0)
AN
Alex S.
Добрый вечер. Подскажите пожалуйста насколько корректна с точки зрения общей практики такая конструкция
Есть некоторый параметризованный фабричный метод (передается "param0") который создает объект класса
Класс в свою очередь реализутет method chaining в виде методов setParamA(paramA: Int) и setParamB(paramB: Float).
В результате получается конструкция:
val obj = factory.createInstance("param0"). setParamA(1).setParam(2.0)
Есть некоторый параметризованный фабричный метод (передается "param0") который создает объект класса
Класс в свою очередь реализутет method chaining в виде методов setParamA(paramA: Int) и setParamB(paramB: Float).
В результате получается конструкция:
val obj = factory.createInstance("param0"). setParamA(1).setParam(2.0)
Ну вроде нормально, только вопрос зачем делать именно так?
BP
Alex S.
Добрый вечер. Подскажите пожалуйста насколько корректна с точки зрения общей практики такая конструкция
Есть некоторый параметризованный фабричный метод (передается "param0") который создает объект класса
Класс в свою очередь реализутет method chaining в виде методов setParamA(paramA: Int) и setParamB(paramB: Float).
В результате получается конструкция:
val obj = factory.createInstance("param0"). setParamA(1).setParam(2.0)
Есть некоторый параметризованный фабричный метод (передается "param0") который создает объект класса
Класс в свою очередь реализутет method chaining в виде методов setParamA(paramA: Int) и setParamB(paramB: Float).
В результате получается конструкция:
val obj = factory.createInstance("param0"). setParamA(1).setParam(2.0)
Ну обычно делаю интерфейсы, а реально объект - один либо пару, зависимости от сложности.
Ну и да это на джаву смахивает
Ну и да это на джаву смахивает
с#
Alex S.
Добрый вечер. Подскажите пожалуйста насколько корректна с точки зрения общей практики такая конструкция
Есть некоторый параметризованный фабричный метод (передается "param0") который создает объект класса
Класс в свою очередь реализутет method chaining в виде методов setParamA(paramA: Int) и setParamB(paramB: Float).
В результате получается конструкция:
val obj = factory.createInstance("param0"). setParamA(1).setParam(2.0)
Есть некоторый параметризованный фабричный метод (передается "param0") который создает объект класса
Класс в свою очередь реализутет method chaining в виде методов setParamA(paramA: Int) и setParamB(paramB: Float).
В результате получается конструкция:
val obj = factory.createInstance("param0"). setParamA(1).setParam(2.0)
почему нет, но можно посмотреть в сторону именнованных параметров или привести цепочки чейн вызовов к просто контексту, типо
factory.createInstance("param0") {
paramA(1)
...
}AS
Идея в том, что фабрика используется для создания объекта и инициализации обязательными параметрами, а дальнейшая цепочка - уже в зависимости от ситуации и может теоретически не вызываться
с#
почему нет, но можно посмотреть в сторону именнованных параметров или привести цепочки чейн вызовов к просто контексту, типо
factory.createInstance("param0") {
paramA(1)
...
}ну это вкус, билдеры через контекст делать, или через чейн методы, но тут прям напрашивается просто так сделать
val obj = factory.createInstance(
"param0",
a = 1,
param = 1.0
)AN
Alex S.
Идея в том, что фабрика используется для создания объекта и инициализации обязательными параметрами, а дальнейшая цепочка - уже в зависимости от ситуации и может теоретически не вызываться
Ну тогда решение @y9san9 гораздо лучше
с#
Alex S.
Идея в том, что фабрика используется для создания объекта и инициализации обязательными параметрами, а дальнейшая цепочка - уже в зависимости от ситуации и может теоретически не вызываться
лямбда может быть optional
AN
Alex S.
Идея в том, что фабрика используется для создания объекта и инициализации обязательными параметрами, а дальнейшая цепочка - уже в зависимости от ситуации и может теоретически не вызываться
А если параметров мало, то опциональные параметры еще лучше
с#
А если параметров мало, то опциональные параметры еще лучше
да, в примере их всего два, тут уже по ситуации решать
AN
Типичный билдер в котлин - это объект с мутабельными полями, который умеет генерировать неизменяемый объект с теми же полями, а вызов билдера выглядит так:
fun MyObject(block: MyObjectBuilde.()->Unit) : MyObject