Здесь (tail, title) — это паатерн-матчинг с паттерном "кортеж".
Но бывают ситуации когда нужно одновременно и произвести декомпозицию кортежа получив одно (или несколько) значений его составляющих, и одновременно иметь возможность манипулировать всем кортежем целиком (например, чтобы вернуть его из функции или передать в качестве параметра).
Конечно можно использовать индексы для получения вложенных значений:
def res = TitleImpl(parags, "H1");
используем res[0] вместо tail и res[1] вместо title
Но использование res[0] и res[1] как-то некрасиво.
Наткнувшись очередной раз на эту ситуацию я вспомнил не однократно повторяемые самим же собой слова "это паттерн" и подумал — раз это паттерн, то я наверно могу использовать паттерн "as". Сам не веря в то, что это сработает я попробовал написать:
Title(parags : list[XElement]) : list[XElement] * string
{
def (_, title) asres = TitleImpl(parags, "H1");
if (title == null)
{
Error(0, "Первым абзацем должен идти заголовок статьи помеченный стилем 'H1'");
(parags, "<<Не задан заголовок статьи>>")
}
elseres
}
и это сработало! Я одновременно получил и кортеж, и значение из него.
Вот это в Немерле мне нравится больше всего. Он работает так как предполагаешь, даже если на первый взгляд предположения кажутся очень смелыми!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вот это в Немерле мне нравится больше всего. Он работает так как предполагаешь, даже если на первый взгляд предположения кажутся очень смелыми!
Поделюсь и своей "Америкой".
Сопоставление с образцом для аргументов-кортежей работает в лямбдах:
H>Этот код из списка свойств формирует строку форматирования для отладчика: \{ a = {a}, b = {b} \}
Скажу больше. В лямбдах исходного синтаксиса он работал всегда. А вот в лямбдах вида (...) => ... он заработал после того как я соответствующий макрос допилил напильником.
Проблема только в том, что про синтаксис as я не знал и по этому, скорее всего код вроде
(f, (prefix, fmt) as y) => ... y
работать не будет .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, z00n, Вы писали:
VD>>и это сработало! Я одновременно получил и кортеж, и значение из него. Z>А в каком языке с паттерн-матчингом это не так?
Здравствуйте, VladD2, Вы писали:
VD>А фиг его знает. Я почему-то вообще не думал, что оно так должно работать. Точнее вот подумал, что хорошо бы чтобы работал, и оно работает .
VD>Раньше я почему-то думал, что это слишком круто чтобы быть правдой.
Это вообще еще из OCaml'а наверно в Немерле перекочевало:
# let (a, b) as c = (123, 124);;
val a : int = 123
val b : int = 124
val c : int * int = (123, 124)
#
Здравствуйте, VladD2, Вы писали:
VD>def fieldToStr(f) { $"$(f.PropertyName) = {$(f.PropertyName)}" }
VD>def debugger_display_fmt = $<#\{ ..$(fields; ", "; fieldToStr) \}#>; VD>[/c#] VD>Это намного проще читать (да и писать тоже) когда привыкаешь к $-нотации.
Сплайс-нотацию знаю, а вот до такого способа использования не додумался. Спасибо.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Зависит от контекста, конечно, но сплайсы использовать еще и безопаснее
Главное, на мой взгляд, то что при их использовании идею проще выцепить. Я чтобы перепсать исходный пример минут 5 внимательно вчитывался в код и пытался понять, что означают эти prefix и fmt. Это как с циклами супротив ФВП. По алгоритму нужно угадать задумку.
В общем, все по IT. Изменение вида сложности. Сложность количественная трансформируется в сложность обучения. Для тех кто въехал в нотацию все становится просто и очевидно. Но при этом могут оказаться люди которые в следствии того, что они не в теме поспримут код "как какие-то кроказябры".
ЗЫ
Но со сплайсингом есть одна проблема. При применении ..$x-нотации формируется код с очень сильно перегруженными методами. В следствии чего даже небольшие объемы могут сильно тормозить. Особенно это заметно при редактирования кода в интеграции. Обходится это дело помещением сплайс-строк в отдельные функции (с явно указанными типами параметров) или даже в отдельные методы.
Надо бы, конечно, заняться этой проблемой. Но времени катастрофически не хватает.
С другой стороны выразительность того стоит. Лучше тратить машинное время, чем время тех кто пишет и читает код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Это тоже из OCaml, там любое объявление — это сопоставление с образцом.
Еще бы из окамла убрать дурацкий, на мой взгляд, синтаксис let ... in, и добавить скобки как в гражданской математики, перегрузку реализовать по человечески и ..., впрочем получился бы Немерле.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Это тоже из OCaml, там любое объявление — это сопоставление с образцом.
VD>Еще бы из окамла убрать дурацкий, на мой взгляд, синтаксис let ... in, и добавить скобки как в гражданской математики, перегрузку реализовать по человечески и ...,
Здравствуйте, VladD2, Вы писали:
VD>А что в ML этого не было?
Было.
Standard ML of New Jersey v110.65 [built: Fri Jun 15 11:06:31 2007]
- val all as (x,y) = (11,12);
val all = (11,12) : int * int
val x = 11 : int
val y = 12 : int
Z>Standard ML of New Jersey v110.65 [built: Fri Jun 15 11:06:31 2007]
Z>- val all as (x,y) = (11,12);
Z>val all = (11,12) : int * int
Z>val x = 11 : int
Z>val y = 12 : int
Z>
Вот и мне казалось, что это все наследие ML-я. Потому оно во всех наследниках и есть.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
.
