ABCNET 0.5.5 (intend)

#1

Версия ABCNET 0.5.5 внесёт множество улучшений и исправлений, в частности будет произведён отказ от стиля PascalABC.NET в пользу NET:

Обратная совместимость, по техническим обстоятельствам, будет нарушена. После обновления возможно будет писать:

Array.By(10, i => i * 2).PrintLine();

, вместо:

Arr.Gen(10, i => i * 2).Println();

Цель версии - сделать библиотеку более понятной для NET-разработчиков, чтобы им не приходилось расшифровывать не общепринятые сокращения.

Discord

Предложить улучшение или сообщить об ошибке

Поддержка: @Alvin-Seville.

#2

Надо наверное эту тему перенести куда-то из рубрики PascalABC.NET. К PascalABC.NET этот топик имеет мало отношения.

#3

Я - не против. Можно перенести в раздел Разное, ибо я не вижу здесь раздела конкретно по NET. Тогда, можно обе темы по данной библиотеке туда перенести.

#4

Что-то вроде “Библиотеки для .NET-среды” ?

#5

Да. Грубо говоря - это NETSquirrel с большим уклоном в обучение и большей совместимостью с языками, которые поддерживают только ссылочные кортежи, и большей простотой.

#6

Array вряд ли будет хорошо выглядеть в Паскале:

&Array.By(10, i -> i * 2).PrintLine();
#7

Да, мы понимаем. Возможен лишь один выход - использовать ABCNET не выше v0.5.0:

Arr.Gen(10, i -> i * 2).Println();
#8

Я не об этом. Вы же пишете, что можно пользоваться и в Паскале.

Тогда в примерах предлагайте следующую форму:

System.Array.
#10

image
image1608×554 36.9 KB

Немного сравнения стилей. Итого:

  • Стиль NET - самый длинный, но и наиболее понятный, ибо количество сокращений сведено к минимуму.
  • Победитель по краткости в большинстве случаев - PABCSystem, но из-за сокращений менее понятен NET-разработчикам, видящих его впервые.
#12

При попытке сохранения обратной совместимости выяснились проблемы - в ABCNET.Extensions её сохранить полностью невозможно. Было принято решение отказаться от неё на совсем ради единообразности. Тем, кому она нужна - придётся использовать ABCNET не выше v0.5.0. Все версии доступны на GitHub.

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

Тексты более ранних сообщений в соответствии с этим будут обновлены.