Агрегация - это владение, совместное (шаренное) владение. А аргентуме агрегатная ссылка может ссылаться только на неизменяемый объект. По такой ссылке можно только читать поля объекта и вызывать константные методы.
Если делать захват объекта и его проверку без участия пользователя, мы сэкономим два символа в исходном тексте программы, но получим несколько проблем:
Из текста будет не ясно, что метод hide может вызваться, а может нет
Программисту некуда будет добавить реакцию на оборванную ссылку (else - часть)
Если после единственной проверки на оборванность ссылки нужно будет сделать несколько взимосвязанных действий не отпуская объекта, без явного оператора "?" это будет проблематично. А сейчас это делается так:
Кстати, "?" это не лишняя конструкция - это бинарный оператор if-then - половинка тернарного оператора if-then-else. Вот про что надо написать! Третий пост будет про управляющие конструкции на основе optional. И про то что в Аргентуме нет bool, а есть optional<void>. Спасибо за коммент.
Реализация std::rc::RcClone (как и все прочие из приведенного списка) не копирует иерархию объектов. Она копирует ссылку на существующий объект, нарушая инвариант UML-композиции, который требует наличия единственного вдалельца. Поэтому Rc ссылка непригодна для организации композитов - а ведь на композитах построены все модели данных в современных приложениях - HTML DOM, Compiler AST, XML-JSON, базы данных, офисные документы, файловые системы, сцены GUI и 3D приложений - это всё композиты. И копирование композитов в Расте приходится писать вручную заново для каждой структуры данных.
А то, если пихать в хешмапу объекты и ключи забывать, то формально утечки вроде нет, а фактически — есть. И говоря про гарантии утечек Rust скорее всего эту ситуацию и имеет ввиду.
Непонятно, что означает фраза "ключи забывать". Определение утечки не должно зависить от внутреннего убеждения программиста о нужности или ненужности данных. Оно должно быть формальным. Все современные программные системы - основанные на ручном управлении, подсчете ссылок и сборке мусора - считают утечкой не освобожденный объект недоступный приложению по владеющим ссылкам.
В аргентуме нет некопируемых структур. Единственность владения обеспечивается не запретом копирования, а удобной встроенной операцией копирования. Let в Swift-e не делает объект константным тогда как оператор заморозки Аргентума - делает.
Спасибо за фидбэк, он поможет мне написать продолжение про встроенные операции и главное, сделать акцент на отличиях от Раста и Свифта.
Каждая композитная (изменяемая) объектная иерархия всегда принадлежит какому-то одному треду. (Хотя ее и можно целиком или по частям передавать между тредами, разбирая и снова собирая в одном треде). Агрегатные иерархии объектов шарятся между всеми тредами, но это не создает проблем, т.к. они не изменяемые.
Можно сказать, что копирование, как и любой доступ к данным в треде с точки зрения других тредов выполняется в транзакции, а с точки зрения кода треда - однопоточен. Поэтому оператор глубокого копирования легко справится с такой иерархией.
Rust позицируется как язык системного программирования, все его сильные и слабые стороны диктуются этим позицированием. Rust не гарантирует отсутствие утечек памяти. Rust фокуссируется на владении и временах жизни стековых и инлайненных объектов (простых и Box-ed), предлагая для сложных структур в хипе указатели Rc, RefCell, которые разрешают шаринг изменяемых объектов циклы и другие архитектурно-опасные решения. Rust не умеет автоматически копировать/клонировать иерархии объектов, соединеных умными указателями, заставляя писать множество опасного кода вручную. Rust любит панику и рантайм проверки.
Аргентум позицируется как язык прикладного уровня: Он гарантирует отсутствие утечек памяти для любого кода, который успешно скомпилировался. Аргентум управляет временем жизни объектов и в стеке и в хипе, он делает это не с помощью явных деклараций lifetimes, а в соответсвии с принципами агрегации-компизиции-ассоциации, что гораздо ближе к предметной области приложений и привычно по UML. Аргентум сам генерирует сервисный код обслуживающий иерархии объектов. Аргентум не позволяет модифицировать шареные объекты, взламывать систему типов кастами, не имеет unsafe режима, не позволяет обращаться по null-pointer и т.д. Он более ограниченный чем Rust но более безопасный.
Автор преувеличивает сложность одностраничных приложений. Вот, например, колхозный одностраничник latis.cc на голом JS без использования каких-либо фреймворков. Вся логика одностраничности помещается в 20 срок (функция goTo + updateState). Не надо на сервере гонять логику UI/UX, пусть он сервает бизнес-логику и модель данных через API и возвращает JSONы.
Агрегация - это владение, совместное (шаренное) владение. А аргентуме агрегатная ссылка может ссылаться только на неизменяемый объект. По такой ссылке можно только читать поля объекта и вызывать константные методы.
Тут: https://aglang.org/how-to-play-with-argentum-in-vscode-based-on-demo-v0-0-1/
Если делать захват объекта и его проверку без участия пользователя, мы сэкономим два символа в исходном тексте программы, но получим несколько проблем:
Из текста будет не ясно, что метод hide может вызваться, а может нет
Программисту некуда будет добавить реакцию на оборванную ссылку (else - часть)
Если после единственной проверки на оборванность ссылки нужно будет сделать несколько взимосвязанных действий не отпуская объекта, без явного оператора "?" это будет проблематично. А сейчас это делается так:
Кстати, "?" это не лишняя конструкция - это бинарный оператор if-then - половинка тернарного оператора if-then-else. Вот про что надо написать! Третий пост будет про управляющие конструкции на основе optional. И про то что в Аргентуме нет bool, а есть optional<void>. Спасибо за коммент.
Реализация
std::rc::RcClone(как и все прочие из приведенного списка) не копирует иерархию объектов. Она копирует ссылку на существующий объект, нарушая инвариант UML-композиции, который требует наличия единственного вдалельца. Поэтому Rc ссылка непригодна для организации композитов - а ведь на композитах построены все модели данных в современных приложениях - HTML DOM, Compiler AST, XML-JSON, базы данных, офисные документы, файловые системы, сцены GUI и 3D приложений - это всё композиты. И копирование композитов в Расте приходится писать вручную заново для каждой структуры данных.Непонятно, что означает фраза "ключи забывать". Определение утечки не должно зависить от внутреннего убеждения программиста о нужности или ненужности данных. Оно должно быть формальным. Все современные программные системы - основанные на ручном управлении, подсчете ссылок и сборке мусора - считают утечкой не освобожденный объект недоступный приложению по владеющим ссылкам.
При таком определении в расте есть утечки, вызванные циклическими ссылками. И архитекторы Раста перекладывают борьбу с этими утечками на плечи программиста. Подробности тут: https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
В аргентуме нет некопируемых структур. Единственность владения обеспечивается не запретом копирования, а удобной встроенной операцией копирования. Let в Swift-e не делает объект константным тогда как оператор заморозки Аргентума - делает.
Спасибо за фидбэк, он поможет мне написать продолжение про встроенные операции и главное, сделать акцент на отличиях от Раста и Свифта.
Каждая композитная (изменяемая) объектная иерархия всегда принадлежит какому-то одному треду. (Хотя ее и можно целиком или по частям передавать между тредами, разбирая и снова собирая в одном треде). Агрегатные иерархии объектов шарятся между всеми тредами, но это не создает проблем, т.к. они не изменяемые.
Можно сказать, что копирование, как и любой доступ к данным в треде с точки зрения других тредов выполняется в транзакции, а с точки зрения кода треда - однопоточен. Поэтому оператор глубокого копирования легко справится с такой иерархией.
Будет. Чисто прикладной язык без стандартного гуя никому не нужен.
Они разные. В некотором смысле - противоположные.
Rust позицируется как язык системного программирования, все его сильные и слабые стороны диктуются этим позицированием. Rust не гарантирует отсутствие утечек памяти. Rust фокуссируется на владении и временах жизни стековых и инлайненных объектов (простых и Box-ed), предлагая для сложных структур в хипе указатели Rc, RefCell, которые разрешают шаринг изменяемых объектов циклы и другие архитектурно-опасные решения. Rust не умеет автоматически копировать/клонировать иерархии объектов, соединеных умными указателями, заставляя писать множество опасного кода вручную. Rust любит панику и рантайм проверки.
Аргентум позицируется как язык прикладного уровня: Он гарантирует отсутствие утечек памяти для любого кода, который успешно скомпилировался. Аргентум управляет временем жизни объектов и в стеке и в хипе, он делает это не с помощью явных деклараций lifetimes, а в соответсвии с принципами агрегации-компизиции-ассоциации, что гораздо ближе к предметной области приложений и привычно по UML. Аргентум сам генерирует сервисный код обслуживающий иерархии объектов. Аргентум не позволяет модифицировать шареные объекты, взламывать систему типов кастами, не имеет unsafe режима, не позволяет обращаться по null-pointer и т.д. Он более ограниченный чем Rust но более безопасный.
Попробуйте решение: https://latis.cc/comment/300. Это grid, и в нем нет никаких костылей.
Автор преувеличивает сложность одностраничных приложений. Вот, например, колхозный одностраничник latis.cc на голом JS без использования каких-либо фреймворков. Вся логика одностраничности помещается в 20 срок (функция goTo + updateState).
Не надо на сервере гонять логику UI/UX, пусть он сервает бизнес-логику и модель данных через API и возвращает JSONы.
Текстовый формат, как JSON или UCL, но:
гораздо меньше синтаксического мусора
не мапы ключ-значение, а объекты с типами, именами и полями
не только деревья, но произвольные стркутуры данных с перекрестными сылками между объектами
можно включать бинарные данные
импорты/экспорты позволяют объединять контент нескольких файлов в один DOM
поддержка C/C++ (DOM/StAX) / Java (DOM/StAX/Сериализация) / JS (Сериализация).
Тут: https://github.com/karol11/cml