Если спросить PHP-разработчиков, какую возможность они хотят увидеть в PHP, большинство назовет дженерики.
Поддержка дженериков на уровне языка была бы наилучшим решением. Но, реализовать их сложно. Мы надеемся, что однажды нативная поддержка станет частью языка, но, вероятно, этого придется ждать несколько лет.
Данная статья покажет, как, используя существующие инструменты, в некоторых случаях с минимальными модификациями, мы можем получить мощь дженериков в PHP уже сейчас.
В этой короткой статье я расскажу о паттерне в 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)
}