В этой короткой статье я расскажу о паттерне в Rust, который позволяет "сохранять" для последующего использования тип, переданный через обобщенный метод. Этот паттерн встречается в исходниках Rust-библиотек и я тоже иногда его использую в своих проектах. Мне не удалось найти в сети публикаций о нем, поэтому я дал ему свое название: "Замыкание обобщенного типа", и в этой статье хочу рассказать, что он из себя представляет, зачем и как его можно использовать.
Для чего в Rust есть ассоциированные типы (associated types), и в чём их отличие от аргументов типов (type arguments aka generics), ведь они так похожи? Разве недостаточно только последних, как во всех нормальных языках? У тех, кто только начинает изучать Rust, а особенно у людей, пришедших из других языков ("Это же дженерики!" — скажет умудрённый годами джавист), такой вопрос возникает регулярно. Давайте разбираться.
TL;DR Первые контролирует вызываемый код, вторые — вызывающий.
Думаю, мы все потихоньку уже привыкаем, что у Python есть аннотации типов: их завезли два релиза назад (3.5) в аннотации функций и методов (PEP 484), и в прошлом релизе (3.6) к переменным (PEP 526).
Так как оба этих PEP были вдохновлены MyPy, расскажу, какие житейские радости и когнитивные диссонансы подстерегали меня при использовании этого статического анализатора, равно как и системы типизации в целом.
Disclamer: я не поднимаю вопрос о необходимости или вредности статической типизациии в Python. Просто рассказываю о подводных камнях, на которые натолкнулся в процессе работы в статически-типизированном контексте.
Да-да, вам не привиделось и вы не ослышались — именно высокого рода. Род (kind) — это термин теории категорий, означающий по сути тип типа [данных].
Но вначале немного лирики.
На Хабре вышло несколько статей, где подробно описывался метод валидации данных в функциональных языках.
Эта статься — мои пять копеек в этот хайп. Мы рассмотрим валидацию данных в Хаскеле.
Ранее было рассмотрен пример методики валидации при помощи валидации типом:
type EmailContactInfo = String
type PostalContactInfo = String
data ContactInfo = EmailOnly EmailContactInfo |
PostOnly PostalContactInfo |
EmailAndPost (EmailContactInfo, PostalContactInfo)
data Person = Person
{ pName :: String,
, pContactInfo :: ContactInfo,
}При помощи этого метода просто невозможно создать некорректные данные. Однако, несмотря на то, что подобную валидацию очень просто создать и читать, использование её заставляет писать много рутины и вносить много изменений в код. А значит, использование подобного метода ограничено лишь для действительно важных данных.
В этой статье мы посмотрим иной метод валидации — при помощи данных высокого рода.
Пусть у нас есть тип данных:
data Person = Person
{ pName :: String
, pAge :: Int
}
И мы будем валидировать данные лишь в том случае, когда валидны все поля записи.
Поскольку Хаскель по функциональным возможностям на голову превосходит большинство функциональных языков, на нём можно легко избавится от большинства рутины.
Тут можно и поэтому данный метод широко используется среди авторов библиотек на Хаскеле.
Читать полностью »
Доброго времени суток. Сегодня наконец-то вновь дошли руки написать сюда. Но в отличие от предыдущих туториалов — статей сегодня хотелось бы поделиться своим опытом и показать мощь такого механизма как дженерики, который вместе с магией спринга становится ещё сильнее. Сразу хочу предупредить, что для понимания статьи нужно знать основы спринга и иметь представления о дженериках большие чем просто “Дженерики это, ну, то что в ArrayList в ковычках указываем”.
Начнём с того, что на работе у меня стояла задача примерно таким образом: имелось большое количество денежных переводов с определенным количеством общих полей. Помимо этого каждому из переводов соответствовали классы — запросы для перевода из одного состояния в другое и перенаправления на другое апи. Соответственно были билдеры, которые и занимались преобразованием.
Проблему с общими полями я решил просто — наследованием. Таким образом у меня появились классы:
public class Transfer {
private TransferType transferType;
...
}
public enum TransferType {
INTERNAL, SWIFT, ...;
}
public class InternalTransfer extends Transfer {
...
}
public class BaseRequest {
...
}
public class InternalRequest extends BaseRequest {
...
}
...
Дальше стояла проблема с контроллерами — у них у всех должны были быть одинаковые методы — checkTransfer, approveTransfer и тд. Вот тут то в первый, но не в последний раз мне пригодились дженерики: я сделал общий контроллер с нужными методами, и унаследовал от него остальные:
Читать полностью »
Не сильно ошибусь, если предположу, что мало кто активно использует эту возможность языка. Для тех кто не помнит, что это такое можно почитать здесь. Я же переду к практике.
Данная публикация является продолжением выпуска, где была затронута тема декорирования объектов. Ознакомление с первой публикацией поможет лучше вникнуть в текущий в контекст, т.к. упомянутые ранее термины и решения буду описываться с упрощениями.
Подход получился весьма удачным и был многократно протестирован на реальных проектах. Кроме этого, появились дополнения к подходу и удобство его использования значительно возросло.
Напомню, что основным элементом представленного способа задания стилей является обобщенное замыкание:
typealias Decoration<T> = (T) -> VoidИспользовать данное замыкание для придания свойств UIView можно следующим образом:
Периодически на хабре можно встретить статьи о том, какие невероятные вещи можно сделать на шаблонах C++: конечные автоматы, лямбда-исчисление, машина Тьюринга и многое другое.
Параметризованные типы в Java традиционно считаются лишь пародией на шаблоны C++ (несмотря на то, что их даже сравнивать как-то некорректно), и причины этого несложно понять. Тем не менее не всё так плохо, и компилятор Java можно заставить производить во время проверки типов любые вычисления, лишь бы хватило оперативной памяти. Конкретный способ это сделать был описан в ноябре 2016-го года в этой прекрасной публикации. Его я и хотел бы объяснить.
Для затравки приведу следующий код. Корректен ли он? Предлагаю скомпилировать и проверить, угадали ли вы результат.
class Sample {
interface BadList<T> extends List<List<? super BadList<? super T>>> {}
public static void main(String[] args) {
BadList<? super String> badList = null;
List<? super BadList<? super String>> list = badList;
}
}Компилятор выбросит java.lang.StackOverflowError независимо от размера стэка.
Разберёмся, почему компилятор ведёт себя именно так (я бы не назвал это багом), как понимание данных причин может быть полезно и причём тут машина Тьюринга.
Простой код на Java: generic интерфейс, класс который его реализует, и метод, принимающий его экземпляр:
//Gen.java:
public interface Gen<A> {
A value();
}
//GenInt.java:
public class GenInt implements Gen<Integer> {
private final int i;
public GenInt(int i) {
this.i = i;
}
@Override
public Integer value() {
return i;
}
}
//GenTest.java:
public class GenTest {
public static <A extends Gen<T>, T> T test(A a) {
return a.value();
}
public static void main(String[] argv) {
GenInt g = new GenInt(42);
Integer i = test(g);
}
}Он компилируется и даже запускается. Как вы думаете, что будет, если вам захочется вызывать метод test из Scala?
object TestFail extends App {
val genInt = new GenInt(42)
val i = GenTest.test(genInt)
}
Всем привет! В данной статье я постараюсь рассказать, что такое generic процедуры и converter’ы в Nim (и показать примеры их использования)
Что такое Nim? Nim – компилируемый (в C, C++, Objective C и JS) высокоуровневый язык программирования со сборщиком мусора, имеющий три основных цели (в порядке приоритета): производительность, выразительность, элегантность. Официальный сайт языка, репозиторий на GitHub.
Также в Nim достаточно развито метапрограммирование (дженерики, шаблоны, макросы).
Читать полностью »