Меня бесят ламеры , class vs Interface

[korvin]

Цитата D_KEY @ 14.06.21, 10:24

Ну val по мне уже должно быть в рантайме. Даже если оно неизменяемое.

С чего ты это взял? )

[D_KEY]

Цитата korvin @ 14.06.21, 10:26

Цитата D_KEY @ 14.06.21, 10:24

Ну val по мне уже должно быть в рантайме. Даже если оно неизменяемое.

С чего ты это взял? )

Ну хз Мне кажется логичным наличие в языке механизма для работы со значениями во время компиляции и так же логичным кажется использовать ключевое слово const.

[korvin]

Цитата D_KEY @ 14.06.21, 10:28

Мне кажется логичным наличие в языке механизма для работы со значениями во время компиляции и так же логичным кажется использовать ключевое слово const.

Это в тебе профдеформация говорит.

[D_KEY]

Цитата korvin @ 14.06.21, 10:36

Цитата D_KEY @ 14.06.21, 10:28

Мне кажется логичным наличие в языке механизма для работы со значениями во время компиляции и так же логичным кажется использовать ключевое слово const.

Это в тебе профдеформация говорит.

Возможно. Но ты раскрой мысль-то про константы.

[korvin]

Цитата D_KEY @ 14.06.21, 10:38

Но ты раскрой мысль-то про константы.

А что там раскрывать? Нет никакой разницы, как называется ключевое слово, хоть const, хоть val, хоть let, хоть def. Возможность работать со значениями во время компиляции от этого никак не зависит.

Сообщение отредактировано: korvin - 14.06.21, 11:09

[D_KEY]

Цитата korvin @ 14.06.21, 11:08

Нет никакой разницы, как называется ключевое слово, хоть const, хоть val, хоть let, хоть def. Возможность работать со значениями во время компиляции от этого никак не зависит.

Суть не в названии, а в наличии возможности. Т.е. смогу ли я потом воспользоваться значением константы для условной компиляции, например? Или для определения размеров массива, хотя бы.
Можешь погуглить про constexpr в C++ или про то, что в D есть.

[korvin]

Цитата D_KEY @ 14.06.21, 11:34

Суть не в названии, а в наличии возможности.

Ну раз суть не в названии, то почему ты докопался до названия? )

Цитата D_KEY @ 14.06.21, 11:34

Т.е. смогу ли я потом воспользоваться значением константы для условной компиляции, например?

Условная компиляция — зло. )

Цитата D_KEY @ 14.06.21, 11:34

Или для определения размеров массива, хотя бы.

Сможешь.

Цитата D_KEY @ 14.06.21, 11:34

Можешь погуглить про constexpr в C++ или про то, что в D есть.

Спасибо, я знаю про constexpr. При чём тут это, не совсем понятно, но можешь тоже погуглить про eval-when в Common Lisp, например. )

Добавлено 14.06.21, 12:11
Или вот.

[D_KEY]

Цитата korvin @ 14.06.21, 12:09

Цитата D_KEY @ 14.06.21, 11:34

Суть не в названии, а в наличии возможности.

Ну раз суть не в названии, то почему ты докопался до названия? )

Да я ж просто сказал, что предпочел бы const для констант

Цитата

Условная компиляция — зло. )

В общем случае нет.

Цитата

Спасибо, я знаю про constexpr. При чём тут это, не совсем понятно

Ну мой const это что-то близкое к constexpr.

По поводу template haskell смотрел когда-то, что-то слабее даже плюсовых шаблонов показалось. Но я подзабыл уже.

Добавлено 14.06.21, 13:05
В любом случае мы отделяем то, что происходит во время компиляции. О чем я и говорю.

[korvin]

Цитата D_KEY @ 14.06.21, 13:04

В общем случае нет.

Да. В том числе и в общем случае. )

Добавлено 14.06.21, 13:20

Цитата D_KEY @ 14.06.21, 13:04

По поводу template haskell смотрел когда-то, что-то слабее даже плюсовых шаблонов показалось.

Оно не совсем прямо соотносится с плюсовыми шаблонами, скорее ближе к макросам лиспа.

[D_KEY]

Цитата korvin @ 14.06.21, 13:19

Цитата D_KEY @ 14.06.21, 13:04

В общем случае нет.

Да. В том числе и в общем случае.

Аргументы-то есть?

[sergioK]

Цитата korvin @ 14.06.21, 07:03

Цитата sergioK @ 14.06.21, 03:49

Покажи не велосипед

val resultCode = -1

не val а var и начиная с 10 версии, которая не LTS, с 11 пока мало где можно выходить в продакшен,
ждем 17 вроде до сентября ,

А ты Я давно заметил крутой спец в Яве, раньше стеснялся говорить,

[korvin]

Цитата sergioK @ 14.06.21, 18:51

не val а var и начиная с 10 версии, которая не LTS, с 11 пока мало где можно выходить в продакшен,
ждем 17 вроде до сентября ,

Не Java, а любой нормальный язык, начиная с… 1970-х примерно.

[Felan]

Вроде не протухла же тема?

Я как поимевший дела с индусами могу сказать, что, думаю, что они это делают, что бы от самих себя защититься. Вообще, делать интерфейсы с константами нормальная практика с незапамятных времен. И нет в ней ничего плохого.

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

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

Ну и с архитекторской т.з. это все выглядит немного криво, потому что они в диаграммах в основном сидят. А тут прямоугольничек, который вроде как и можно использовать определенным способом, но никогда не нужно. Людей с ОКР это раздражает, я знаю

[sergioK]

Цитата Felan @ 15.07.21, 19:04

Вроде не протухла же тема?

Ой как раз в тему,
У меня command pattern и при инициализация я свои классы с ключами гружу в map ,
И все бы хорошо, но вдруг главный индус архитектор мне его убирает - аргументация
у них есть fresh developers и им тяжело использовать фабрику , обычный switch
лучше

     switch key {
  
     case 1:
         return channel1Service.download(..)
    case 2:
        return channel2Service.download(..)
 
      и т,д
}

У было

  IService service = factory.getService(int key )

И тут Я понимаю что по неволе становлюсь расистом Эти индусы вообще реальные системы
писали ? И только схемы рисовали ? Если у них fresh developer и счас не умеет работать паттернами ,
так как он научиться тогда , мои джуны прекрасно с фабрикой работали.

[Felan]

Ну тут я с индусом соглашусь.

Насколько я понял из объедков кода, это не фабрика а фабричный метод. Хотя и он тут не к чему. Это должно называться Сервис локатор.

Вообще, архитектурные паттерны очень похожи друг на друга. И они не про рантайм. Они про статическую структуру. Про то как взаимодействуют классы, а не объекты. Поэтому и важно привильно их применять. По сути, фабричный метод вполне может заменить сервис локатор. В принципе и то и то будет работать. Даже можно сказать одинаково. Но когда один архитектор будет разговаривать с другим, они буду понимать определенные нюансы связанные с каждым паттерном. Потенциальные пути расширения функционала. Не все что можно навесить на одно, можно навесить на другое без потери "архитектуры" извиняюсь за тавтологию .

А данном случае, зачем здесь фабричный метод? Его вывод не зависит от статики, от действительного типа объекта в рантайме. Он зависит только от параметра. Так что да. Простой кейс тут более уместен, ну в крайнем случае сервис локатор (я не знаю подробностей).

А индусы они в общем тоже разные бывают. Как и все остальные. Но специфика культурного кода присутствует конечно

ЗЫЖ Интересно посмотреть оригинал переписки... мало ли, че там они на ломаном басурманском накорябали, кто чего не понимает