Size: a a a

2019 August 02

ŹR

Źmićer Rubinštejn in pro.elixir
Покажи мне такой код
источник

V

V in pro.elixir
Application.make_me_pizdato() например.
Это не суть совершенно. Суть в том, что эти приватные методы приватны именно затем, чтобы другие части приложения их не вызывали, быть невидимыми для них. И вынос приватных методов в модуль с публичными методами рушит эту идею. Это то же самое что использовать def вместо defp.
источник

ŹR

Źmićer Rubinštejn in pro.elixir
По твоей логике в каждой программе должен быть только одна публичная функция, которая вызывается на старте приложения
источник

ŹR

Źmićer Rubinštejn in pro.elixir
По этой же логике, если у меня есть библиотека, которую я вызываю в одном месте своего кода, но МОГУ вызывать в любом другом месте своего кода - "пизда все пропало"
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Идея разрушилась...
источник

ŹR

Źmićer Rubinštejn in pro.elixir
deps надо подгружать походу внутри функции
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Чтобы в другие функции случайно не просачилось
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Вот например модуль Json.Helpers

https://github.com/michalmuskala/jason/blob/master/lib/helpers.ex

Им не пользуется никто кроме Jason. Пиздец идее...
источник

V

V in pro.elixir
Źmićer Rubinštejn
По твоей логике в каждой программе должен быть только одна публичная функция, которая вызывается на старте приложения
Гротескно. Нет. Это иллюстрация к тому, что засовывать большие куски функционала в модули
- с одной стороны удобно потому что можно повысить уровень абстракций и сузить интерфейсы
- а с другой стороны неудобно потому что нужно тестировать приватный функционал тоже.
И разруливание этого противоречия - одна из задач архитектуры.
источник

V

V in pro.elixir
Źmićer Rubinštejn
По этой же логике, если у меня есть библиотека, которую я вызываю в одном месте своего кода, но МОГУ вызывать в любом другом месте своего кода - "пизда все пропало"
Скажем, не с библиотеками, а с их частями или отдельными методами. Да, это проблема, пропорциональна размеру команды и текучке.
источник
2019 August 03

d

dimiii in pro.elixir
V
Application.make_me_pizdato() например.
Это не суть совершенно. Суть в том, что эти приватные методы приватны именно затем, чтобы другие части приложения их не вызывали, быть невидимыми для них. И вынос приватных методов в модуль с публичными методами рушит эту идею. Это то же самое что использовать def вместо defp.
А  что такого, если кто-то и вызовет? Состояния-то нет :p
источник

d

dimiii in pro.elixir
V
Чтобы было понятнее - представь, что под def sum скрывается 40 уровней вложенности. И цикломатическая сложность sum довольно высока.
Можно попробовать писать код по-другому, использовать протоколы, например. Так квази-приватные станут публичными и тестируемыми, если я правильно понял пример с NumberOperations
источник

Е

Евгений in pro.elixir
dimiii
А  что такого, если кто-то и вызовет? Состояния-то нет :p
состояние может и быть, эликсир не хаскель
источник

DR

Dmitry Russ (Aleksandrov) in pro.elixir
V
Гротескно. Нет. Это иллюстрация к тому, что засовывать большие куски функционала в модули
- с одной стороны удобно потому что можно повысить уровень абстракций и сузить интерфейсы
- а с другой стороны неудобно потому что нужно тестировать приватный функционал тоже.
И разруливание этого противоречия - одна из задач архитектуры.
Я буду достаточно категоричен. Я не понимаю, откуда вообще может взяться проблема или необходимость тестирования приватных функций?? Публичных функций всегда больше, модулей всегда больше, чем количество публичных функций/модулей, которые имеет смысл тестировать. В любом, не минимальном проекте, который я видел - это было так.

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

DR

Dmitry Russ (Aleksandrov) in pro.elixir
Поэтому менять defp -> def _ звучит как попытка решить проблему, которой не существует. И может нужно разбираться в коде, что в нём не так, если возникла такая необходимость.
источник

Е

Евгений in pro.elixir
V
Это нормальный вопрос. Кто, когда и почему решил, что я как программист и автор кода (и не только я) не могу сам выбрать минимальный уровень детализации?
Вот пример
defmodule NumberOperations do
   def sum(a, b), do: do_sum(a, b)
   defp do_sum(%Complex{} = a, %Complex{} = b), do: ...
   defp do_sum(a, b), do: a + b
end
Хочу покрыть юнит-тестами функцию для комплексных чисел. Что, её в отдельный модуль выносить что ли?
Тогда надо еще возмутиться почему нельзя выбрать уровень детализации при котором можно юниттестировать отдельные строки внутри функции. Чего это коварные разработчики ограничивают гуттаперчивых программистов?
источник

DR

Dmitry Russ (Aleksandrov) in pro.elixir
Евгений
Тогда надо еще возмутиться почему нельзя выбрать уровень детализации при котором можно юниттестировать отдельные строки внутри функции. Чего это коварные разработчики ограничивают гуттаперчивых программистов?
take MyApp.function on line:42, set var foo = 42, execute till line:45, assert bar = 45 👍😭
источник

V

V in pro.elixir
dimiii
Можно попробовать писать код по-другому, использовать протоколы, например. Так квази-приватные станут публичными и тестируемыми, если я правильно понял пример с NumberOperations
Можешь привести пример, как это сделать?
источник

d

dimiii in pro.elixir
V
Можешь привести пример, как это сделать?
defprotocol NumberOperations do
 def sum(a, b)
 # ...
end

defimpl NumberOperations, for: Complex do
 # def sum(a, b), do: ...
 # ..
end

defimpl NumberOperations, for: Rational do
 # def sum(a, b), do: ...
 # ..
end
источник

d

dimiii in pro.elixir
Забавно, хотел взять в качестве примера Monoid, но оказалось:
> ** (ArgumentError) protocol functions expect at least one argument
ЧЗХ?
источник