Рубрика «closure»
Интерфейсы-протоколы для начинающих
2022-03-08 в 15:16, admin, рубрики: beginners, closure, iOS, iOS разработка, junior developer, swift, swift разработка, xcode, для начинающих, протокол, птицы, разработка под iOSПеремещение — прошлый век! Альтернативы std::move в «C++ будущего»
2020-01-17 в 13:41, admin, рубрики: autoclosure, c++, closure, lambda, lazy, move semantics, proposal, relocation, замыкание, ленивые вычисления, лямбда, перемещение, ПрограммированиеКаждый раз, когда мы пишем класс, управляющий ресурсами, мы задумываемся о том, что, скорее всего, для него придётся писать move-конструктор и move-присваивание. Ведь иначе объекты такого типа становятся неуклюжими, как std::mutex
, ими тяжело пользоваться на практике: ни вернуть из функции, ни передать в функцию по значению, ни положить в вектор — а если положить его в другой класс как один из членов, то тот класс также «заболевает».
Положим, мы преодолели свою лень (хотя в Rust таких проблем нет!) и садимся писать move-операции для нашего класса. Проблема в том, что move-семантика в C++ имеет фундаментальное ограничение: каждый владеющий ресурсами тип с move-операциями должен иметь пустое состояние, то есть состояние с украденными ресурсами. Его нужно описывать в документации и предоставлять ему поддержку, то есть тратить время и силы на то, что нам не нужно.
Для абстрактных типов данных пустое состояние обычно бессмысленно — если у объекта украли его ресурсы, то он не сможет выполнять свои обычные функции. Но мы вынуждены это делать, чтобы реализовать move-семантику. Для некоторых типов пустое состояние недопустимо: open_file
(в противовес теоретическому file
), not_null_unique_ptr<T>
(в противовес unique_ptr<T>
).
Говоря словами Arthur O'Dwyer, мы заказывали телепорт, а нам дали «вас клонируют и убивают первоначальную копию». Чтобы вернуть себе телепорт, проходите под кат!
Что ты такое, замыкания в JavaScript?
2019-07-08 в 9:20, admin, рубрики: closure, javascript, замыкание в java script, замыкание переменных, замыкания, замыкания в javascriptВ этой статье я постараюсь разобрать механизм реализации замыканий в JavaScript. Для этого я буду использовать браузер Chrome.
Начнем с определения:
Замыкания - это функции, ссылающиеся на независимые (свободные) переменные. Другими словами, функция, определённая в замыкании, 'запоминает' окружение, в котором она была создана.
Если вам что-то не понятно в этом определении, это не страшно. Просто читайте дальше.
Я глубоко убежден, что разбираться в чем-либо проще и быстрее на конкретных примерах.
Поэтому предлагаю взять фрагмент кода и пройтись по нему вместе с интерпретатором от начала до конца по шагам и разбираться по ходу, что происходит.
Итак, приступим:
Рисунок 1
Читать полностью »
Замыкание обобщенного типа в Rust
2019-05-31 в 12:38, admin, рубрики: Any, closure, downcast, generics, Rust, замыкание, обобщенные типы, приведение типа, Программирование
В этой короткой статье я расскажу о паттерне в Rust, который позволяет "сохранять" для последующего использования тип, переданный через обобщенный метод. Этот паттерн встречается в исходниках Rust-библиотек и я тоже иногда его использую в своих проектах. Мне не удалось найти в сети публикаций о нем, поэтому я дал ему свое название: "Замыкание обобщенного типа", и в этой статье хочу рассказать, что он из себя представляет, зачем и как его можно использовать.
Новое в Git 3: замыкания
2019-03-31 в 23:00, admin, рубрики: 1 апреля, closure, Git, loop, кто-то читает тегиGit — популярная система контроля версий. В ней атомарное изменение одного или нескольких файлов называется коммитом, а несколько последовательно идущих коммитов объединяются в ветку. Ветки используются для того, чтобы реализовывать новые идеи (фичи).
Случается, что идея оказывается тупиковой, разработчик сворачивает не туда, и возникает необходимость отката к изначальной версии, для этого нужно забыть о новой ветви и переключиться на главную dev или master, и затем продолжить работу как ни в чем не бывало. В этом случае "отросток" повиснет навсегда, как и желание его удалить. Но как удалить, если это часть истории? Этот отросток показывает усилия трудяги-программиста, пусть и тщетные. Так легче отчитываться перед начальством, ведь неудачный результат — тоже результат!
Спешу обрадовать: разработчики Git в 3 версии введут новую команду для замыкания таких беспризорных ветвей. Напомню, что текущая актуальная версия — 2.21.0.
Как использовать эту команду, что она дает и что думают IT компании? Статья отвечает на эти и другие вопросы.
Привет, Habr! Сегодня хочу рассказать про свой костыль, который помог мне не погружаться в дебри PHP Reflection. Ведь все пишут костыли, просто кто-то пишет большие, а кто-то поменьше.
JVM не такая тяжёлая
2017-03-22 в 10:11, admin, рубрики: closure, java, jvm, Node, node.js, ruby, ruby on railsВ основном ответ на то, что Clojure — это JVM. Мол, эта хрень такая тяжёлая.
Это появилось на канале ZA Tech в группе Slack несколько недель назад. Во время некоторых выступлений по Clojure спикеры делали такое замечание снова и снова.
По этому поводу я выступил в Slack. Теперь запишу для более широкого чтения и обсуждения.
Предисловие
Я тоже раньше думал, что JVM тяжёлая. Это было в начале 2000-х, в сравнении с PHP. Там были и другие тяжеловесы, вроде .NET и ColdFusion. Были и более лёгкие альтернативы вроде Perl и Python, но я тогда сидел на Windows, так что ActivePerl и ActivePython тоже были несколько тяжеловаты.
Впервые я преодолел свой «страх» перед JVM, когда развернул небольшое производственное приложение JRuby на Heroku. Этот маленький монстрик должен был выполнять только одну задачу в день. Он генерировал ряд PDF'ов, потом загружал их на iSign (сейчас не функционирует) для хранения и распространения. Сам iSign был классическим приложением Rails, которое хостилось на трёх AMI. Этот маленький динозавр на стоковом JVM (за исключением -server -Xmx=512M
) производил PDF'ки так быстро, что он буквально убивал трёхнодовый кластер при каждом запуске.
Я по-прежнему думал, что он немного тяжеловат в работе, но влюбился в этого гадкого утёнка.
Читать полностью »
Второй митап функциональных программистов в Москве (Erlang, Clojure и другие функциональные штуки)
2016-02-24 в 13:31, admin, рубрики: closure, erlang, Erlang/OTP, functional language, functional programming, functional thinking, javascript, Node, ruby, функциональное программирование
Что будет: доклады, пицца, общение, отличный вечер четверга.
Список заявленных докладчиков и тем под катом.
Читать полностью »
Реактивный манифест
2013-09-28 в 10:44, admin, рубрики: actors, akka, asynchronous, callbacks, closure, clusters, distributed computing, elasticity, erlangvm, event loops, event-driven programming, failover, fault handling, fault tolerant, functional programming, futures, http, hyperthreading, immutability, interactive, jvm, lambda, latency, load balancing, location transparency, louse coupling, multicore, multithreading, network, no side effects, observable, Observer, parallel computing, performance, play framework, promises, pure functions, push-model, referential transparency, reliability, remoting, resilience, responsiveness, rxjava, scalability, self-heal, supervisors, synchronization, thread-safety, web applications, Анализ и проектирование систем, параллельное программированиеВ последние годы требования к приложениям значительно изменились. Десятки серверов, время отклика в несколько секунд, оффлайновое обслуживание, которое могло длиться часами, гигабайты данных — такими были большие приложения буквально несколько лет назад. Сегодня же приложения работают абсолютно на всём, начиная с простых мобильников и заканчивая кластерами из тысячи процессоров. Пользователи ожидают миллисекундного времени отклика и стопроцентного аптайма, в то время как данные выросли до петабайтов.
Первоначально эту нишу занимали крупные инновационные интернет-компании типа Google или Twitter, однако такие требования к приложениям начали всплывать во многих областях индустрии. Финансовые и телекоммуникационные компании первыми начали внедрять новые практики, чтобы удовлетворить новым требованиям, а теперь подтягиваются и остальные.
Новые требования требуют новых технологий. Предыдущие решения делали упор на управляемые сервера и контейнеры. Масштабирование достигалось засчёт покупки более крутых серверов и использования многопоточности. Для добавления новых серверов приходилось применять комплексные, неэффективные и дорогие проприетарные решения.
Однако прогресс не стоит на месте. Архитектура приложений эволюционировала в соответствии с изменившимися требованиями. Приложения, разработанные на основе этой архитектуры, мы называем Реактивными Приложениями. Такая архитектура позволяет программистам создавать событийно-ориентированные, масштабируемые, отказоустойчивые и отзывчивые приложения — приложения, работающие в реальном времени и обеспечивающие хорошее время реакции, основанные на масштабируемом и отказоустойчивом стеке и которые легко развернуть на многоядерных и облачных архитектурах. Эти особенности критически важны для реактивности.
Отложенная обработка массива
2012-09-10 в 8:49, admin, рубрики: closure, javascript, socket.io, метки: closure, javascript, socket.io Однажды, при разработке сложного приложения на JavaScript-е возникла непреодолимая проблема — большой массив в Internet Explorer (далее IE). Так как я изначально проверял работу в Chrom-е, то не замечал каких-либо проблем при использовании массивов. Скажу больше — вложенные массивы не вызывали чувства страха. Chrom легко справлялся с трудными задачами. Однако IE, в очень жёсткой форме, указал на все мои огрехи и недостатки кода, особенно на обработку Больших массивов.
Читать полностью »