Программирование[11]

Just.Doit написал 13 минут назад:

в контексте статической валидации типов - это одно и тоже

либо я не понял твоего тейка

Ты питон называешь статически типизированным языком. В каком еще контексте? 

Just.Doit написал 7 минут назад:

ребята, вы знакомы с таким разделом знаний как теория типов?

Тип это несколько больше чем коментарий для человека.

GoldRobot написал 4 минуты назад:

Тип это несколько больше чем коментарий для человека.

чел блять

там не комментарий для человека

там тайп хинт

который валидируется статически тайп чекером

ау блять

GoldRobot написал 5 минут назад:

Ты питон называешь статически типизированным языком.

нет. я говорю что по вашему принципу можно питон называть статически типизированным потому что там можно проверять статически типы

Чел. Еще раз. Тип это несколько больше чем коментарий. Статическая типизация это не несколько больше чем код через mypy прогнать или глазками почитать.

Just.Doit написал 1 час назад:

оу май

?

Index написал 27 минут назад:

Kant написал 43 минуты назад:

Index написал 49 минут назад:

У меня вот дилема. 

У меня есть система в ней по сути два крупных домена данных. Один домен это приложения, товары в приложениях и тд и тп.

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

 

Естественно все это сегрегировано по разным рестам /applications и /templates

  Offtopic

Хотя применение шаблона к приложению я сделал как 

@Post("/{applicationId}/templates/{templateId}") чисто потому что я хуй знает как это сделать не вводя отдельный сервисный домен. Хотя блять возможно его и стоило ввести исходя из текста ниже.

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

И я хуй знает на каком уровне эти 2 домена должны соединяться.

Грубо говоря 

1) Слой контроллера приложений (Контроллер приложений вызывает сервис приложений, потом сервис шаблонов)

2) Слой сервиса приложений (Сервис приложений вызывает сервис шаблонов) однозначно не хочу это решение так как есть вероятность что я потом в цикличных зависимостях зашьюсь да и вообще уебищно как-то.

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

 

Почему мне это нравится? Потому что то что для пользователя выглядит как одна волшебная кнопка по сути работа с двумя разными доменами данных (с соблюдением хэпенс бефор)

Почему мне это не нравится? Потому что идет 2 http кола, и если первый отработает как надо а второй нет то пользователь может быть в недоумении.

 

  Показать содержимое

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

и обновление двух доменов с хэпенс бефор

 

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

Она не совсем двунаправленная. 

Одно направление шаблон -> (применяется к) -> приложение.

Второе на уровне БД. Данные о приложениях -> (через вьюшки и селекты) -> используются для рассчета инишиал стейта шаблона.

 

Т.е с точки зрения внешнего управления есть явная первая связь.

А по волшебной кнопке мне нужно по сути тригернуть вторую.

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

@Controller("/templates")
...
@Put("/{id}") Mono<Template> updateTemplate(@PathVariable Integer id, @Body TemplateRefresh templateRefresh)

Просто блять не атомарно и уебищно выглядит. 

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

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

тогда никаких вопросов атомарности и не стоит

А как интерпретатор питона может проверить типы статически? Вот я указываю, что моя функция принимает int. Туда передается переменная, полученная из какой-то библиотеки. Как статически понять, что тип передаваемый в функцию некорректен?

Kant написал Только что:

Index написал 30 минут назад:

Kant написал 46 минут назад:

Index написал 52 минуты назад:

У меня вот дилема. 

У меня есть система в ней по сути два крупных домена данных. Один домен это приложения, товары в приложениях и тд и тп.

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

 

Естественно все это сегрегировано по разным рестам /applications и /templates

  Offtopic

Хотя применение шаблона к приложению я сделал как 

@Post("/{applicationId}/templates/{templateId}") чисто потому что я хуй знает как это сделать не вводя отдельный сервисный домен. Хотя блять возможно его и стоило ввести исходя из текста ниже.

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

И я хуй знает на каком уровне эти 2 домена должны соединяться.

Грубо говоря 

1) Слой контроллера приложений (Контроллер приложений вызывает сервис приложений, потом сервис шаблонов)

2) Слой сервиса приложений (Сервис приложений вызывает сервис шаблонов) однозначно не хочу это решение так как есть вероятность что я потом в цикличных зависимостях зашьюсь да и вообще уебищно как-то.

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

 

Почему мне это нравится? Потому что то что для пользователя выглядит как одна волшебная кнопка по сути работа с двумя разными доменами данных (с соблюдением хэпенс бефор)

Почему мне это не нравится? Потому что идет 2 http кола, и если первый отработает как надо а второй нет то пользователь может быть в недоумении.

 

  Показать содержимое

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

и обновление двух доменов с хэпенс бефор

 

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

Она не совсем двунаправленная. 

Одно направление шаблон -> (применяется к) -> приложение.

Второе на уровне БД. Данные о приложениях -> (через вьюшки и селекты) -> используются для рассчета инишиал стейта шаблона.

 

Т.е с точки зрения внешнего управления есть явная первая связь.

А по волшебной кнопке мне нужно по сути тригернуть вторую.

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

@Controller("/templates")
...
@Put("/{id}") Mono<Template> updateTemplate(@PathVariable Integer id, @Body TemplateRefresh templateRefresh)

Просто блять не атомарно и уебищно выглядит. 

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

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

тогда никаких вопросов атомарности и не стоит

Шаблонов может быть N приложений может быть M

Любой шаблон из множества N может быть применен к любому приложению из множества M

В рассчете дефолтного стейта шаблона используются данные по всем приложениям из множества M

Ну и связей принадлежности

>приложение будет иметь свою копию шаблона

там нет.

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

Это снизит зацепление доменов друг о друга и позволит отдельно работать с ними как CRUD и отдельно делать кросдоменные взаимодействия 

позвольте поднасрать:

for (int i = 1; argv[i]; ++i){

    // это Н_О_Р_М_А

}

Olololnet написал Только что:

позвольте поднасрать:

 

for (int i = 1; argv; ++i({

    // это Н_О_Р_М_А

}

 

В чем прикол?

Grohuf написал Только что:

В чем прикол?

вот сейчас равно задумке

GoldRobot написал 14 минут назад:

Статическая типизация это не несколько больше чем код через mypy прогнать или глазками почитать.

в том контексте в котором ведется речь - нет. это именно то чем является типизация в питоне, это именно статическая типизация

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

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

В питоне можно сделать ветвление исходя из типа? 

А гетерогенные коллекции?

besteady написал 12 минут назад:

?

да просто кажется в 2к23 это дефолт уже примерно везде а говорится как будто невиданная инновация

вон у них даже в плюсах это есть, со слов байтоебов

Index написал 1 минуту назад:

В питоне можно сделать ветвление исходя из типа? 

А гетерогенные коллекции?

но мы говорили про статическую типизацию а не про райнтайм, энивей

А составные типы в питоне есть? 

Index написал 1 минуту назад:

А составные типы в питоне есть? 

погугли сам, ты заебал

насчет мощности ситсемы типов в питоне я не знаю. подозреваю что она очень примитивная (чуть хуже джавы)

Короче, я еще раз убедился, что дастдуит полный кретин. Не понимать, что такое статическая типизация - это мощно.

Grohuf написал 16 минут назад:

А как интерпретатор питона может проверить типы статически?

берет и проверяет, по правилам проверки типов

и не интерпретатор а проверяльщик типов

интерпретатору, дефолтному, это не нужно. потому что он блятьь интерпретирует

хотя могли впилить какие-то оптимизации или еще что-то

Grohuf написал 2 минуты назад:

Короче, я еще раз убедился, что дастдуит полный кретин. Не понимать, что такое статическая типизация - это мощно.

чел. в чем я не прав. выше описано что такое статическая типизация

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

но это все просто в плюсах именно так реализовано. само понятие статической типизации этим не ограничено

я понимаю что почти все плюсовики конченые

но не настолько же...

Just.Doit написал 4 минуты назад:

чел. в чем я не прав. выше описано что такое статическая типизация

Статическая типизация - это когда до выполнения кода известен тип переменной. Это позволяет, в частности, выделять под переменную ровно столько памяти, сколько нужно. В питоне, в общем случае, тип переменной не известен. Хинты могут помочь, чтобы валидировать типы после написания кода, но сторонняя утилита тебе никак не поможет, если ты подключаешь библиотеку без указания типов. Кроме того, можно спокойно запустить программу, даже если утилитка ругается. Поэтому в питоне динамическая типизация. И в общем случае об ошибке ты узнаешь, когда исполнится нужная строчка кода. То есть в рантайме.

Just.Doit написал 16 минут назад:

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

Питоновский интерпретатор это не может сделать.

Он даже в рантайме когда дойдет до твоей функции, варнинг тебе не высрет, если ты отдашь не те аргументы.

Just.Doit написал 16 минут назад:

в том контексте в котором ведется речь - нет. это именно то чем является типизация в питоне, это именно статическая типизация

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

Какой еще контекст? Что ты там невыдумывал себе?

Чел. Ты в говно сел уже давно, зачем вертишься?

Хотя зато мы теперь все знаем что ты считаешь питон статически типизируемым языком.

И что ты даже питона не знаешь базово, хотя бахвалился этим очень много.

Grohuf написал 22 минуты назад:

А как интерпретатор питона может проверить типы статически? Вот я указываю, что моя функция принимает int. Туда передается переменная, полученная из какой-то библиотеки. Как статически понять, что тип передаваемый в функцию некорректен?

Да никак.

Есть отдельные, 3rd-party софтинки типа mypy. https://mypy.readthedocs.io/en/stable/

Они на основе коментариев о типах (у этих коментах даже формат утвердили недавно и назвали type_hint), может попытаться поанализировать и сказать че да где там.

Дуит на основе их наличия думал что питон статически типизированный язык, потому что увидел в документации к софтине static.

Теперь пытается выкрутиться и налить нам воды, как он делал это всегда до этого. В конце пукнет снова "Я прихожу сюда просто посрать. Хочу и пизжу", или как он тогда сформулировал.

Grohuf написал Только что:

В питоне, в общем случае, тип переменной не известен

ну речь не про общзий случай

а про случай использование статической типизации

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

GoldRobot написал 1 минуту назад:

Питоновский интерпретатор это не может сделать.

я выше ничего не говорил про один какой-то конкретный питоний интерпретатор (ты кстати про какой-то конкретный из них или сразу про все?)

GoldRobot написал 1 минуту назад:

Чел. Ты в говно сел уже давно, зачем вертишься?

да нет. я во всем прав

вы почему-то надумали себе что должен быть компилятор который типы проверяет

и что должны быть оптимизации выделения памяти на основе типов

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

ну тоесть я прав во всем (почти)

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