Содержание

Unyson — Плагин для WordPress

  • Детали
  • Отзывы
  • Установка
  • Разработка

Поддержка

Did you find this plugin helpful? Please consider leaving a 5-star review.

Unyson — A free drag & drop framework that comes with a bunch of built in extensions that will help you develop premium themes fast & easy.

Sponsored by: BitBlox.me

Features include:

  • Drag & Drop Page Builder. Create countless pages using the content and media shortcodes.
  • Backup & Demo Content. Create an automated backup schedule, import demo content or even create a demo content archive for migration purposes.
  • Sliders. To make you life even easier we have already built in 3 of them that support images and videos.
  • Mega Menu. User-friendly drop down menu that will let you easily create highly customized menu configurations.
  • Sidebars. This module will let your users customize WordPress pages with dynamic sidebars.
  • Portfolio. Portfolio has some pretty neat filtering animations.
  • Breadcrumbs. A pretty small module that will really come in handy when you’ll want to navigate your website faster.
  • Forms Use the drag & drop form builder to create any contact form you’ll ever want or need.
  • SEO. SEO settings at finger tips without installing further plugins.
  • Feedback. We’ve added a way for users to submit reviews and ratings for events, projects, etc.
  • Events. It’s pretty simple to use and it has Calendar and Map shortcodes.

Get involved

Developers can contribute to the source code on the Unyson GitHub Repository.

Translators can contribute new languages to Unyson through Transifex.

Theme developers can test the compatibility of their themes with new extensions updates before they are going to be released on Unyson Extensions Approval.

WP-CLI INTEGRATION IS INCLUDED

  • Unyson CLI
  • Create a page by adding the columns structure you want.
  • Then add content shortcodes to your liking from the Content Elements and Media Elements tabs.
  • All the portfolio entries have thumbs for easy identification.
  • Unyson comes with a built in Events Extension.
  • Create backups directly from the WordPress admin.
Минимальные требования
  • WordPress 4.0 или выше
  • PHP версии 5.2.4 или выше
  • MySQL версии 5.0 или новее
Установка
  1. Upload the unyson folder to the /wp-content/plugins/ directory
  2. Активируйте плагин Unyson через вкладку ‘Плагины’ в административной панели WordPress
  3. Configure the plugin by going to the Unyson menu that appears in your admin menu

Где я могу найти документацию по Unison?

For extending or theming Unyson, see developers documetation.

Где я могу сообщить о найденных ошибках или внести вклад в проект?

You can open issues via Unyson Github Repository Issues page.

Будет ли Unyson работать с моей темой?

Yes; Unyson will work with any theme.

The blog posts are empty. I am using WordPress 6.1 and PHP 8. If I deactivate the Unyson plugin it works. Please update the theme!

This plugin does not work properly anymore. Makes errors in backups, and worsens the loading time. It is also not compatible with the new wordpress version and breaks the website.

Constantly spamming ads in the admin console

Love it, please update everytime

Same as lots of users. Just be aware that if you use this extension, your site will crash for no reason when you update the extension or deactivate it ! Goof luck to the brave users !

My client is using a theme that uses this extension.

Crashed our site trying to update it.

Посмотреть все 94 отзыва

«Unyson» — проект с открытым исходным кодом. В развитие плагина внесли свой вклад следующие участники:

Участники

  • Unyson

Перевести «Unyson» на ваш язык.

Заинтересованы в разработке?

Посмотрите код, проверьте SVN репозиторий, или подпишитесь на журнал разработки по RSS.

2.7.28
  • Fixed #4276,#3861,#4275
2.7.27
  • Security Issue
2.7.26
  • Fixed #4211
2.7.25
  • Fixed #4209
2.7.24
  • Fixed #3915
2.7.23
  • Fixed #3915,#3861,#3750,#3888,#3738
2.7.22
  • Fixed #3716,#3561
2.7.20
  • Fixed #3629
2.7.19
  • Security Issue
2.7.18
  • Fixed #3480,#3474,#3468
2.7.17
  • Fixed #3442,#3397,#3399
2.7.16
  • Remove redirects to about Brizy page
2.
7.15
  • Urgent update
2.7.14
  • Fixed #3365,#2732
2.7.13
  • Fixed #3344,#3309,#3300,#3302,#2898,#3182,#3194
2.7.12
  • Fixed #3092,#3093,#3044,#3113,#3113,#3132,#3133,#3109,#100,#8,#3137
2.7.11
  • Fixed #3052,#3050,#3044,#3043,#3014
    ,#3008,#3006,#3071,#3061
2.7.10
  • Fixed #2997,#2999
2.7.9
  • Fixed #1351,#2716,#2833,#2736,#2718,#2953,#2888,#2855,#2906
2.7.8
  • Fixed #2905,#2862,#2909,#2924,#2925,#2921,#2844
2.7.7
  • Fixed #2832,#2862,#2781,#2732,#2703
2.7.6
  • Urgent update
2.7.5
  • Urgent update
2.7.1
  • Bug fixes
2.7.0
  • Fixed #2460,#1775,#2516#2536#1419#2563#2587#2591#2604
  • New feature. Introducing Reactive Option Types
2.6.15
  • Fixed #2490, #2450, #326
2.
6.15
  • Fixed #2380, #2397, #2212
2.6.14
  • Fixed infinite loop when php memory limit is -1
  • Небольшие изменения
2.6.13
  • Fixed #2310, #2308, #961, #2073
2.6.12
  • Fixed #2283, #2265, #2286, #2288
2.6.11
  • Fixed #2198, #2216, #2219, #2234, #2254, #2264, #2265, #2273
  • Option-type multi-select improvements
  • Option-type multi-picker: The same options can be used for multiple choices #2251
  • Autoload a lot of classes #2225
  • New helper function fw_get_path_url()
  • Deprecated warning for the save-in-separate-meta option parameter
  • Deleted FW_File_Cache helper
2.6.10
  • Fixed #2216, #2212, #2214
2.6.9
  • Fixed #1743, #2143, #2148, #2154, #2159, #2139, #2167, #2179, #2180
2.6.8
  • Extensions are installed on plugin install with TGM
    'is_automatic' => true     #2117
  • Fixed #2134, #2104, #2106, #1144
2.
6.7
  • Fixed #2053, #2024
2.6.6
  • Disabled File Cache #2029
  • Added option-type addable-popup-full #1769
  • Fixed #2034, #2025, #2031
2.6.5
  • Minor fixes
2.6.4
  • Fixed #2000
2.6.3
  • Fixed #1993
2.6.2
  • Option-types must be loaded on fw_option_types_init action #1827
  • Option-type icon-v2 refactor
  • Fixed #1491, #1979, #1970, #1954
2.6.1
  • Hotfix in File Cache #1968
2.6.0
  • Added File Cache #1828
  • Migration to native term meta #1745
  • The possibility to register Available Extensions from theme
  • Fixed #1860, #1877, #1897, #1810
2.5.12
  • Fixed wp-editor option error when used in Theme Settings #1860
2.5.11
  • New extension: WordPress Shortcodes #1807
  • Option type wp-editor fixes #1615
  • Performance improvement in fw_get_db_. .._option() functions
  • Added javascript helper fw.soleConfirm #1803
2.5.10
  • Fixed fw_get_db_customizer_option() bug #1796
2.5.9
  • Fixed missing function in WP < 4.5 #1767
  • New option-type: icon-v2
  • Fixed wp-editor option-type bugs #1739
  • Process fw-storage parameter in all options (Theme Settings, Customizer, Post, Term, Extension Settings) #1551
2.5.8
  • Fixed wp-editor bugs
  • Updated FontAwesome
  • Fixed #1676
2.5.7
  • #1682, #1687, #1647
2.5.6
  • Minor fixes
2.5.5
  • Fixed #1586
2.5.4
  • Fixed #1423, #1517, #1509, #1386, #1488, #837, #1538, #1484
2.5.3
  • Fixed option-type wp-editor issues: #1472, #1475, #1478
  • Improvements in fw_get_db_post_option()
  • Updated FontAwesome to v4. 6.1
2.5.2
  • Fixed option-type wp-editor issues #15
  • Taxonomy options now are displayed on Add Term page #1427
  • Added the wp-customizer-setting-args parameter for customizer options #1435
  • Added translations: Nederlands, Русский
  • Updated Español translations
  • Fixed #1449, #1438, #1278, #1443, #1440
2.5.1
  • Fixed #1062, #1278, #1292, #1293, #1310, #1295, #767, #1322, #1323, #1321, #1054, #1309, #1347, #2777093, #1355, #1354, #1379, #1394, #1391, #1403
  • Fixes for WP 4.5 BackboneJS & UnderscoreJS latest version
2.5.0

  • Added the possibility to save options in separate database location #838

    Will be used in next release of the PageBuilder extension, the builder value will be moved to a separate post meta.

  • Lazy Tabs: Render only the visible tabs #1174

    This feature can be disabled by adding in {theme}/framework-customizations/theme/config. php:

    $cfg['lazy_tabs'] = false;

  • Added the .pot file #1256

  • Fixed #1072, #1052, #1235, #1236, #1251, #1246, #1242, #941, #1250, #1243, #1261

Оценки

Посмотреть все

  • 5 звёзд 60
  • 4 звезды 2
  • 3 звезды 3
  • 2 звезды 1
  • 1 звезда 28

Войдите, чтобы оставить отзыв.

Участники

  • Unyson

Поддержка

Решено проблем за последние 2 месяца:

0 из 1

Перейти в форум поддержки

Разработка iOS Framework в унисон с помощью Swift и Objective-C / Хабр

Прошло много времени с тех пор, как язык программирования Swift был представлен на WWDC в 2014 году. С тех пор внедрение Swift сторонними разработчиками, безусловно, было массовым. Тем не менее, Objective‑C всё ещё существует.

В этом посте мы предоставим несколько советов и приёмов для успешной разработки XCFrameworks (новые способы упаковки и поставки библиотек в различных вариантах). XCFrameworks сочетают Swift и Objective‑C таким образом, чтобы совместимость языков не ставила под угрозу публичные API‑интерфейсы фреймворка и не влияла на них.

Swift vs Objective-C

Действительно, можно утверждать, что разработка Objective‑C за последние несколько лет продвигалась вперед только благодаря Swift. Но также реальностью является и то, что Objective‑C по‑прежнему является наиболее используемым языком программирования в системе iOS(см. диаграмму ниже, предоставленную компанией Apple: Apple»s use of Swift and SwiftUI in iOS 16). Похоже, что Swift потребуется ещё несколько лет, чтобы превзойти Objective‑C в этом отношении.

Если говорить о сторонних разработчиках для платформ Apple то, несмотря на то, что Swift теперь является языком программирования по умолчанию, есть несколько причин, по которым некоторые базы кода могут по‑прежнему содержать изрядное количество кода Objective‑C:

  • В зависимости от API‑интерфейсов C++, которые можно вызывать только из Objective‑C (до тех пор, пока не будет добавлена совместимость Swift и C++).

  • Имеют старую существующую кодовую базу Objective‑C, которую можно или нельзя легко перенести на Swift.

Если мы добавим в уравнение Swift, то это, скорее всего, означает, что коды Swift и Objective‑C должны взаимодействовать. Эта интероперабельность (способность к взаимодействию, совместимость) относительно проста при работе в App target:

  • Код Objective‑C можно импортировать в Swiftс помощью связующего заголовка Objective‑C и добавления к нему всех файлов заголовков, которые необходимо предоставить Swift.

  • Код Swift можно импортировать в Objective‑C, импортировав автоматически сгенерированный заголовок, содержащий публичные или открытые интерфейсы Swift, которые можно подключить к Objective‑C. Например, перечисления Swift (enum) со связанными значениями нельзя использовать в Objective‑C.

Совместимость Swift и Objective-C в framework target

Возникает множество нюансов, когда нам необходимо, чтобы Swift и Objective‑C взаимодействовали в рамках framework target. Причина в том, что для того, чтобы код на одном языке был доступен на другом, он должен быть публичным (за некоторыми исключениями). Но что мы можем сделать, если эти интероперабельные интерфейсы не должны быть публичными?

Прежде чем вдаваться в подробности, давайте вернёмся назад и ответим на следующий вопрос: почему вас это должно беспокоить?

Разработка публичного API фреймворка — непростая задача. API должен быть хорошо документирован, чётко структурирован и прост в использовании. Следовательно, если эти интерфейсы взаимодействия будут публичными, это только добавит путаницы в публичные API‑интерфейсы нашего фреймворка. Более того, автодополнение кода предложит интегратору использовать эти публичные, но не предназначенные для общего доступа API. Мы не должны путать интегратор нашей структуры с классами или методами, которые не предназначены для вызова их кода. Кроме того, может быть ещё одна причина. Может ли вызов этих интерфейсов взаимодействия API повлиять на поведение нашего фреймворка? Иногда использование этих API может привести к непредсказуемой или неправильной работе фреймворка. Хотя комментарий: DO NOT USE, вероятно, мог бы помочь, он не может препятствовать интеграторам вызывать эти API по ошибке (или намеренно).

Надеюсь, на данный момент вы, вероятно, убеждены, что мы не должны отказываться от чистоты нашего публичного API только для обеспечения совместимости Swift‑Objective‑C в реализации фреймворка. Давайте посмотрим, как мы можем этого добиться.

Импорт кода Objective-C в Swift внутри фреймворка

В этом разделе мы предлагаем обходной путь для очистки совместимых внутренних API‑интерфейсов Objective‑C от публичного API‑интерфейса нашей платформы, чтобы Swift внутри платформы мог видеть эти API‑интерфейсы Objective‑C, а интеграторы не имели такой возможности. Прежде чем углубляться, мы должны уточнить, что этот обходной путь может применяться только к фреймворкам, распространяемым в двоичной форме (XCFramework). Приведённое ниже решение не может быть применено к фреймворкам в форме исходного кода, поскольку оно основано на сценарии очистки, выполняемом сразу после создания XCFramework.

Согласно документации Apple, импорт кода Objective‑C в Swift в рамках целевой платформы достигается путём импорта заголовков Objective‑C, которые должны быть представлены Swift в заголовке зонтика платформы. Заголовок зонтика (главный заголовок) — это файл FrameworkName.h, который должен содержать список всех импортов для всех публичных заголовков фреймворка. Обратите внимание, что этот зонтичный заголовок является публичным. Фактически, это должен быть единственный заголовочный файл, который необходимо импортировать интеграторам, чтобы начать использовать фреймворк:

import <FrameworkName/FrameworkName.h>

Swift автоматически увидит все заголовки, импортированные в зонтичный заголовок, но то же самое сделают и интеграторы фреймворка, потому что все заголовки, включенные в зонтичный заголовок, должны быть публичными.

Мы объясним, как можно использовать скрипт для удаления всех заголовков Objective‑C, которые не должны быть публичными, из XCFramework. Мы проиллюстрируем это на изображениях, соответствующих гипотетической среде под названием MyFramework, где нам необходимо предоставить Swift класс InternalClass класса Objective‑C.

Первый шаг — опубликовать все заголовки Objective‑C, которые должны быть видны Swift. В противном случае мы бы даже не смогли построить фреймворк. Для этого нам необходимо:

Теперь вы можете использовать InternalClass из Swift (но помните, что на данный момент интеграторы тоже имеют такую возможность).

class MySwiftClass {                                 
    let objcClass = InternalClass()
}

Вторым этапом является подготовка к зонтичному заголовку, возможной будущей сценарию, быстро публичные заголовки, которые необходимо удалить из результирующего XCFramework. Чтобы упростить сценарий, мы можем добавить метку комментария к заголовку зонтика. Сценарий будет искать эту метку на поэтапном шаге и удалять все файлы заголовков, импортированные после метки.

Мы использовали метку__INTERNAL__, но подходит любая метка. Убедитесь, что этот текстовый знак не может появиться где‑либо ещё в заголовке зонтика. В данном случае скрипт не будет работать должным образом.

Третий и последний шаг — сценарий, который будет реализован после создания XCFramework и позволит получить действие:

  1. Читает головной убор и ищет метку __INTERNAL__ .

  2. Удаляет все файлы заголовков, импортированные в заголовок чехла после метки __INTERNAL__ .

  3. Удаляет строку, содержащую метку __INTERNAL__ , и все последующие строки.

Мы назовём его removeInternalHeaders.sh, и с этого момента будем предполагать, что у нас уже есть фреймворк MyFramework.xcframework( здесьвы можете проверить, как сгенерировать XCFrameworks). Наш сценарий благоприятный вариант, путь к XCFramework, чтобы удалить публичные заголовки Objective‑C, которые должны быть внутренними.

#! /bin/sh -e
#
# removeInternalHeaders.sh
#
## 1
XCFRAMEWORK_DIR=$1
INTERNAL_MARK="__INTERNAL__"
## 2
function removeInternalHeadersInUmbrellaHeader {
  local framework_name="$(basename $1 .framework)"
  local headers_dir="$1/Headers"
  local umbrella_header_file="$headers_dir/$framework_name.h"
  local internal_mark_found=false
  local internal_headers=()
  ## 2.1
  while read -r line; do
    if $internal_mark_found; then
      if [[ $line == "#import"* ]]; then
        local filename=$(sed 's/.*\"\(.*\)\".*/\1/' <<< $line)
        internal_headers[${#internal_headers[@]}]=$filename
      fi
    elif [[ $line == *$INTERNAL_MARK* ]]; then
        internal_mark_found=true
    fi
  done < $umbrella_header_file
  ## 2.2
  echo "${#internal_headers[@]} files will be removed"
  for filename in ${internal_headers[@]}; do
    local file="$headers_dir/$filename"
    if [ -f "$file" ]; then
      rm $file
      echo "Removed file: $file"
    else
      echo "Tried to remove file but it does not exist: $file"
    fi    
  done
  ## 2. 3
  sed -i "" '/'$INTERNAL_MARK'/,$d' $umbrella_header_file 
}
## 3
for directory in ${XCFRAMEWORK_DIR}/**/*.framework; do
  [ -d "$directory" ] || continue
  removeInternalHeadersInUmbrellaHeader $directory
done

Давайте углубимся в детали. Обратите внимание, что мы добавили в код скрипта несколько тегов типа ## X. Мы будем использовать их для пояснений:

  • Скрипт получает путь к XCFramework ($1) и объявляет метку, идентифицирующую общедоступные, но внутренние заголовки. Эта отметка должна точно совпадать с меткой, добавленной в заголовок зонтика (в нашем случае — «__INTERNAL__»).

  • Поскольку XCFramework — это просто набор фреймворков и библиотек, нам потребуется повторить процесс очистки для каждого элемента внутри XCFramework. Вот почему мы определяем функцию removeInternalHeadersInUmbrellaHeader: чтобы избежать повторения одного и того же кода для каждого элемента. Эта функция считывает заголовок зонтика, строка за строкой, пока не найдёт первую строку, содержащую метку __INTERNAL__. Для всех последующих строк зонтичного заголовка он добавляет каждое имя импортированного файла в массив internal_headers, чтобы отслеживать файл заголовка, который впоследствии будет удалён. Каждое имя файла получается путём извлечения текста между кавычками в строке. Затем функция удаляет файлы, собранные в массив internal_headers. Наконец, функция редактирует заголовок зонтика, чтобы удалить строку, содержащую метку __INTERNAL__, и все последующие строки, поскольку файлы заголовков, указанные в этих строках, были удалены из фреймворка.

  • В этом случае XCFramework объединяет один или несколько фреймворков. Поэтому функция removeInternalHeadersInUmbrellaHeader должна выполняться для всех фреймворков.

Обратите внимание, что скрипт рассматривает только импорт файлов с двойными кавычками. Его можно легко изменить, чтобы он также включал импорт с угловыми скобками: #import.

После выполнения removeInternalHeaders. shи передачи ему пути к XCFramework мы можем убедиться, что файл InternalClass.hудалён и больше не импортируется в заголовок зонтика.

Структура папок фреймворка после удаления публичных заголовков, которые должны были быть внутренними:

Заголовок зонтика после запуска скрипта для удаления публичных заголовков после метки __INTERNAL__:

Интеграторы, использующие XCFramework, не смогут получить доступ к InternalClass.

Импорт кода Swift в Objective-C внутри фреймворка

В этом разделе мы намерены использовать интероперабельность в противоположном направлении. Мы хотим использовать символы Swift в коде Objective‑C в нашем фреймворке.

Опять же, мы ссылаемся на документацию Apple, подчеркивая, что для использования кода Swift в файлах Objective‑C.m нам необходимо импортировать сгенерированный Xcode заголовок для кода Swift. В нашем примере выше это будет файл MyFramework‑Swift.h. Однако этот файл является публичным и, по сути, включает только объявления Swift, помеченные модификатором public или open. Это означает, что если у нас есть внутренний класс Swift, совместимый с Objective‑C (либо с использованием внутреннего модификатора, либо без модификатора), этот класс не будет включен в заголовок, сгенерированный Xcode. Похоже, мы сталкиваемся с той же проблемой, что и раньше.

Однако есть один возможный обходной путь. На странице документации Apple мы можем прочитать следующее:

[…]. Методы и свойства, отмеченные модификатором internal и объявленные в классе, который наследуется от класса Objective‑C, доступны во время выполнения Objective‑C. Однако они недоступны во время компиляции и не отображаются в сгенерированном заголовке для framework target.

Это дает нам подсказку. Поскольку Objective‑C может получить доступ к этим внутренним символам Swift во время выполнения, возможно, нам нужно помочь Objective‑C получить к ним доступ во время компиляции. Можем ли мы как‑то добиться этого? Что ж, есть хорошие новости. Да, это возможно. Давайте посмотрим, как.

Ключ в том, чтобы наш внутренний заголовок объявлял внутренние символы кода Swift для Objective‑C. Этот внутренний заголовок должен включать те же интерфейсы, которые в противном случае были бы добавлены в открытый заголовок ‑Swift.h, сгенерированный Xcode.

Внимание. Решение, которое мы предлагаем далее, имеет свои проблемы и риски:

  • Это не так идеально или удобно, как если бы интерфейсы, соединяющие код Objective‑C, автоматически генерировались средой Xcode для нас.

  • Это опасно, потому что есть некоторый объём ручной работы по обслуживанию: объявления Objective‑C во внутреннем заголовочном файле необходимо обновить, если мы изменим символы Swift, которые они соединяют.

Но он работает и сохраняет наши публичные API чистыми и ограниченными желаемым публичным интерфейсом фреймворка.

Поясним, как это сделать, на примере. Предположим, что нам необходимо получить доступ к следующему классу InternalSwiftClass из Objective‑C в нашем фреймворке, не объявив его public или open.

Как указывалось выше, поскольку этот класс не имеет модификатора public или open, файл MyFramework-Swift.h не включает интерфейсы Objective-C для этого класса Swift.

Небольшой совет: вы можете получить доступ к содержимому файла -Swift.h, сгенерированного Xcode, с помощью Xcode. Для этого импортируйте файл в формате .m (в нашем примере с #import ), выполните cmd + клик на import, а затем нажмите “Jump to Definition”.

Давайте создадим наш внутренний заголовок, который будет содержать внутренние интерфейсы Swift. В нашем примере мы назовём этот файл MyFramework-Swift-Internal.h. Убедитесь, что файл включен в framework target с уровнем доступа Project и что он импортирует фактически сгенерированный Xcode заголовок -Swift.h.

Теперь нам необходимо объявить в этом файле интерфейсы Objective‑C класса InternalSwiftClass. Это деликатный шаг потому, что интерфейсы Swift преобразуются в Objective‑C. Мы рекомендуем использовать очень простой трюк, чтобы позволить Xcode сделать преобразование для нас, устраняя риск сделать какие‑либо ошибки или опечатки. Хитрость состоит во временном добавлении модификатора public к объявлениям, чтобы интерфейсы могли быть добавлены в заголовочный файл, сгенерированный средой Xcode.

Соберите проект (cmd + b) и откройте файл заголовка, сгенерированный Xcode. Там вы увидите интерфейс Objective-C для нашего класса Swift:

Скопируйте объявления @interface (включая часть SWIFT_CLASS(…)) и вставьте их в созданный нами внутренний файл заголовка. Не забываем удалить временный модификатор public для нашего интерфейса Swift (в примере в файле InternalSwiftClass.swift).

И это всё. Теперь вы можете вызывать внутренние интерфейсы Swift из Objective-C из файлов .m, импортировав только что созданный внутренний файл заголовка.

Важное примечание: не забывайте обновлять внутренний заголовок всякий раз, когда вы вносите какие-либо изменения во внутренние интерфейсы Swift, которые будут использоваться из Objective-C. В противном случае ваш проект соберётся, но вылетит во время выполнения!

Чтобы избежать этого, вы можете написать несколько модульных тестов на Objective-C, которые используют эти мостовые API из Swift. С помощью этих юнит-тестов вы можете отловить такого рода оплошности, прежде чем выпускать какое-либо обновление для вашей платформы.

Разработка платформы iOS с несколькими языками отнюдь не проста. Во Fleksy мы работали и с Objective-C, и со Swift вместе. Если вы хотите обсудить эту статью или вам нужна помощь с вашим проектом, не стесняйтесь обращаться к нам напрямую или через наш сервер Discord. Наша команда будет рада помочь вам.

Язык Unison

Новый подход к

Распределенное программирование

Больше не нужно писать кодировщики и декодеры в каждой сети граница. Скажите, где вы хотите, чтобы выполнялись вычисления, и это бывает 🔮 — Зависимости разворачиваются на лету.

Подробнее

Рефакторинг

Ваша кодовая база всегда активна и проверяется тип, даже в середина рефакторинга. Unison провел структурированный рефакторинг сеансы, а не большой вводящий в заблуждение список ошибок типов.

Подробнее

Долговременное хранение

Больше не нужно писать код перевода между вашими значениями и слой хранения. Непосредственно сохраняйте значения и отключайте их позже не опасаясь конфликтов зависимостей или несоответствия версий.

Подробнее

Код для хранения

Другие инструменты пытаются восстановить структуру текста; Магазины Юнисон код в базе данных. Это устраняет сборки, обеспечивает мгновенные неразрывные переименования, поиск по типу и многое другое.

Подробнее

Зависимости

Многие конфликты зависимостей возникают из-за того, что определения конкурируют за одни и те же имена. Поскольку Unison вместо этого ссылается на код по хэшу по имени можно устранить целый класс конфликтов.

Узнать больше

Unison — дружественный язык программирования от будущее: статически типизированное, функциональное и очень веселое 😄

$

Вкл. Apple Silicon ? Вам понадобится Розетта, чтобы запустить Unison.

Загрузите последнюю версию с GitHub

💡 Все части примеров кода интерактивны. Щелкните зависимость, чтобы прочитать ее определение и документацию.

Классическая программа Hello World в Unison так же проста, как вызов printLine.

{IO, Exception} указывает, какие способности необходимы программе для выполнения ввода-вывода и создания исключений.

'

используется для обозначения отложенного вычисления.

Узнайте больше о способностях.

С помощью нескольких строк кода вы можете выполнить распределенное уменьшение карты, используя способность Remote .

Узнайте больше о Remote и работе с распределенными наборами данных в Unison.

Выполнение эффективного кода, такого как HTTP-запросы с обработчиками AbilitiesandAbility.

Ознакомьтесь с другими примерами HTTP в библиотеке thestew.http.

Когда вы пишете, Unison Codebase Manager (UCM) всегда рядом с вами. сопровождение вас в процессе разработки
; добавление, обновление и запуск ваших программ.

👋 Добро пожаловать в Юнисон!
.>

© 2023

Unison Computing, общественно-полезная корпорация

и участники.

👀 Краткий обзор Unison · Язык программирования Unison

Этот документ содержит фрагменты кода с минимальным описанием. Ссылки предоставляются на более полные разделы документов. Если вы еще не загрузили UCM, вы можете сделать это в первую очередь. 😎

Многие примеры кода и фрагменты здесь кликабельны! Они ссылаются на определения исходного кода и документы.

Hello World

Запишите свой код Unison в любой файл .u с суффиксом «scratch».

Классическая программа helloWorld выполняет взаимодействие с консолью через способность IO. Узнайте, как способности моделируют эффекты в Unison.

Выполните точку входа в вашу программу с помощью команды run UCM.

 .> запустите helloWorld

Или добавьте свою программу helloWorld в кодовую базу и запустите ее, упаковав в двоичный исполняемый файл!

 .> добавить
.> compile helloWorld helloFile

Это создаст исполняемый файл с именем helloFile.uc в том же каталоге, что и кодовая база. Затем вы можете запустить свою программу в своем терминале.

 $ ucm run.compiled helloFile.uc

📚Узнайте больше о выполнении программ Unison

Основные функции

Ниже представлена ​​функция double с одним параметром. Соглашения Unison для определения функций подробно описаны здесь

90 078 взгляд.двойной : Нат -> Нат взгляд.двойной х = использовать нат * х * 2 
 > двойной 4

> в рабочем файле запускает функцию double в выражении awatch.

📚Тур Unison знакомит с выражениями часов и другими функциями рабочего процесса

Синтаксис отложенных вычислений

Символ ' — это синтаксический сахар для знакомства с athunkand ! Символ — это синтаксический сахар для вызова преобразователь.

В Unison отрицание логического значения осуществляется с помощью Boolean, а не . ! зарезервировано для вызова отложенных вычислений.
 приветствие : Текст -> Текст
Приветствуйте имя =
  использовать текст++
  "Привет" ++ имя 
 delayGreet : 'Текст
delayGreet = '(приветствовать "Joy")

Более подробный обзор отложенных вычислений

Литералы списка

Квадратные скобки вводят список Unison.

  [0, 1, 2, 3] Список.++ [4, 5] 
  ⧨ 
 
 [0, 1, 2, 3, 4, 5]

Список .++ наш оператор для объединения списков.

  голова =
  использовать список +:
  1 +: [2, 3, 4]
голова :+ 5 
  ⧨ 
 
 [1, 2, 3, 4, 5]

Для списков доступны различные шаблоны списков.

📚Подробнее об общих типах коллекций в Unison

Преобразования списков

Оператор |> представляет собой «конвейер», который передает результат выполнения выражения слева в качестве аргумента функции справа.

Аргумент x -> x Nat.* 100 в скобках для List.map является примером лямбда-выражений в Unison.

📚Узнайте больше об операторах, таких как |>

if/else и сопоставлении с образцом

Приведенное ниже выражение написано с использованием синтаксиса if then и else и синтаксиса сопоставления с образцом

 use Nat mod
isEven1 число =
  используйте нат ==
  если mod num 2 == 0, то true иначе false
isEven2 = случаи
  н | мод n 2 === 0 -> истина
  _ -> false

Функции сопоставления шаблонов Unison включают привязку переменных, защиту шаблонов (разделенные | ) и шаблоны as (обозначаются цифрой 9). 0056 @ ).

  совпадение Некоторые 12 с
  Нет -> "нет"
  Некоторые п| Nat.isEven n -> "n является переменной, а | является защитой шаблона"
  opt@(Some n) -> "opt связывается со всем необязательным значением" 
  ⧨ 
 
 "n является переменной и | является защитой шаблона"

Объявления типов

Унисонный тип данных с уникальностью, определяемой его name:

 уникальный тип LivingThings

Рекурсивный тип данных Tree с одним параметром типа:

 структурный тип look.Tree a

Структурное ключевое слово означает, что типы, определенные с одинаковой структурой, идентичны.

Подробнее о типах данных и разнице между структурными и уникальными.

Типы записей позволяют вам называть поля вашего типа.

 уникальный тип Pet = {
   возраст: Нат,
   виды : Текст,
   едаПредпочтения : [Текст]
}

При создании типа записи создается ряд вспомогательных методов для доступа и обновления полей типа данных.

 .> add Pet

Углубленный синтаксис типа записи

Обработка исключений

Исключение «возбуждается» с помощью способности Exception и «перехватывается» обработчиком.

Наш документ по обработке ошибок с помощью возможностей подробно описывает этот шаблон и другие типы ошибок.

Использование способностей

Способности используются для управления эффектами в Unison.

Выбирает случайный элемент из списка с помощью Random.natIn , функции, использующей способность Random.

splitmix — пример обработчика возможностей.

Распределенные вычисления

Распределенные вычисления могут быть выражены на самом языке Unison с помощью возможности Remote . Прочтите о возможности Remote и ее функциях много разных узлов в кластере. Этот вариант использования распределенных вычислений был подробно описан в статье.

Отправка HTTP-запроса

Извлечение библиотеки из Unison Share с помощью команды pull .

 .> pull stew.public.projects.httpclient.latest lib.httpclient

В первой части этого кода используются конструкторы данных из библиотеки http для создания полного uri из полномочий и пути. Запрос обрабатывается путем передачи его обработчику HTTP.

В библиотеке http есть отличные документы!

Основные операции с файлами

Операции с файлами выполняются путем установки FileMode и манипулирование файлом Handle .Поиск по файлу можно выполнить с помощью функции getBytes , которую мы решили выполнить в функции arecursive.

Эти и другие файловые функции расположены в пространстве имен base.io .

 .> найти файл

Примитивы параллелизма

Примитивы параллелизма, такие как MVar , TVar и STM , встроены в базовую библиотеку. TVar и STM упрощают создание неблокирующих параллельных изменяемых структур данных.

No related posts.