Size: a a a

2020 October 16

МБ

Максим Барулин... in pro.elixir
т.е строка из 2 символов
источник

МБ

Максим Барулин... in pro.elixir
а, проглядел первую часть
источник

M

MrFlorius in pro.elixir
не, строка из одного из разрешенных символов, 3 цифр, и двух разрешенных символов
источник

M

MrFlorius in pro.elixir
а не работало из за русских букв в паттерне
источник

МБ

Максим Барулин... in pro.elixir
ну да, если кирилица надо обязательно /u добавлять
источник

M

MrFlorius in pro.elixir
ну да, логично
источник

LL

Lama Lover in pro.elixir
Чат, я выпустил версию 1.0.0 библиотеки Pathex для функциональных линз
В документации есть детальные примеры того как это может облегчить вашу жизнь и реально сэкономить время
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Lama Lover
Чат, я выпустил версию 1.0.0 библиотеки Pathex для функциональных линз
В документации есть детальные примеры того как это может облегчить вашу жизнь и реально сэкономить время
Я думаю, что Pathex.~>/2 надо задеприкейтить и вместо неё использовать Pathex.path when is_function

Что скажешь?
источник

ŹR

Źmićer Rubinštejn in pro.elixir
А ещё, при использовании переменной по-моему надо брать ее с ^. Тогда получается консистентный с “экто и другими dsl” api
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Кстати, я чет подумал, и понял что я хз почему в экто надо делать ^
источник

LL

Lama Lover in pro.elixir
Źmićer Rubinštejn
Я думаю, что Pathex.~>/2 надо задеприкейтить и вместо неё использовать Pathex.path when is_function

Что скажешь?
Не получится, Pathex.path генерирует код в компайле, а в компайле отличить функцию от переменной невозможно, а генерить лишний case для этого будет душным и неочевидным
Да и потом, никто не гарантирует что функция будет другим Path-ом
Ну и наконец, я планирую написать код который будет оптимизировать последовательный вызов нескольких ~>, типа v1 ~> v2 ~> v3 будут генерить одно замыкание, а не два (я такое уже сделал для &&&)
источник

ŹR

Źmićer Rubinštejn in pro.elixir
> Да и потом, никто не гарантирует что функция будет другим Path-ом

А сейчас ты как это проверяешь?
источник

ŹR

Źmićer Rubinštejn in pro.elixir
&(&1) ~> path не сработает чтоли в компайл тайм?
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Или даже в рантайм именно на этой строчке?
источник

ŹR

Źmićer Rubinštejn in pro.elixir
А не на строчке где ты вызовешь ее
источник

LL

Lama Lover in pro.elixir
Źmićer Rubinštejn
> Да и потом, никто не гарантирует что функция будет другим Path-ом

А сейчас ты как это проверяешь?
Никак, строю замыкание скрестив пальцы. Разница в том, что если у меня вызывается ~> то я знаю, что слева и справа должны быть функции, иначе ничего не получится
А в Pathex.path не получится отличить функцию от, например, переменной или константы, не пихая отдельный case
Ну а главное, мне лично кажется что explicit должен побеждать implicit, особенно в случае с макросами
Но я подумаю над твоей идеей
источник

ŹR

Źmićer Rubinštejn in pro.elixir
В отдельном кейсе я проблемы не вижу. А вот в неконсистентности АПИ я вижу проблему
источник

LL

Lama Lover in pro.elixir
Źmićer Rubinštejn
В отдельном кейсе я проблемы не вижу. А вот в неконсистентности АПИ я вижу проблему
Ну по логике в Pathex.path 1 / 2 / x / y все элементы (1, 2, x, y) должны быть ключами к структурам, будь то индекс или ключ мапа. Проводить тут композицию двух линз будет ещё боле неконсистентно
источник

ŹR

Źmićer Rubinštejn in pro.elixir
path1 = path :foo / :bar
path2 = path 1 / 2
path3 = path path1 / path2
path4 = path path3 / :bazz
источник

LL

Lama Lover in pro.elixir
Źmićer Rubinštejn
path1 = path :foo / :bar
path2 = path 1 / 2
path3 = path path1 / path2
path4 = path path3 / :bazz
А что делать если у меня на инпут придёт
%{
 (fn x, y -> x + y end) => 1
}

?
источник