В данный момент ведётся активная разработка документации по версии NETSquirrel 0.0.17.2.
На скриншоте примеров документации ниже показано как использовать лямбда-выражения для задания форматной строки-подсказки при вводе элементов массива и обработки ошибок при вводе:
Ага. Работает только в консоли. И кому это может понадобиться - с цветом баловаться?
Баловаться цветом - это было сделано, в частности, для новичков, поскольку им нравится цветное и красивое. Вообще, планируется сделать вывод в произвольный поток.
Не путаете новичков и ворон? Я вот, к примеру, с уверенностью могу сказать, что консоль новичкам вообще не нравится.
Конечно, новичкам сама консоль не очень интересна. Но, разноцветный вывод, думаю, позволит скрасить их жизнь хотя бы в какой-то степени. Во-вторых, такая возможность позволяет в примерах программ, выделять что-то важное и существенное.
Жизнь новичку скрашивает принцип написания максимально короткого кода.
А это вообще новичкам сто лет не интересно. Это может быть интересно авторам каких-то методичек и руководств.
Согласен. Именно поэтому PABCSystem для краткости кода - лучший выбор. NETSquirrel в этом плане проигрывает, однако предоставляет больше в некоторых местах функционала, чем PABCSystem (например, в плане чтения с клавиатуры матриц и массивов). Но, плата за богатый функционал - длина кода.
Тоже согласен.
Что-то свой модуль KTX вспомнил… На уроках иногда в консоли ради прикола много чего выводили)) Так что у нас консоль любили (но не учителя)
Я не думаю, что те, для кого NetSquirrel предназначен, имеют уровень развития 12-14 летнего подростка.
Жаль нам всем по 16-17 было, когда с этого угарали.
А вообще, я написал именно из-за того, что вы сказали, что новички консоль не любят (ибо не умеют её готовить), а в KTX можно не только любые картинки совать
, но и даже игры делать.
А по сути: я считаю это неплохим и даже в какой-то мере полезным нововведением. Не для матриц, а для одномерных массивов строк, например логов, когда ошибки надо выводить одним цветом, предупреждения вторым и так далее. Это сильно улучшает читабельность
Печально, потому что это лишь подтверждает выводы психологов и социологов о том, что нынешняя молодежь сплошь и рядом страдает чрезмерным инфантилизмом.
Да, именно так, в большинстве своих средств библиотека направлена на тех, кто уже знаком с средствами современного программирования (лямбда-выражения, методы расшинения, Linq и т. д…), но хочет ускорить процесс написания кода. Упор при разработке делается на хорошую обратную совместить и качество кода, его оптимизацию и на соответствие стилю Linq. Также, разработка может быть несколько медленнее, чем соответствующего функционала в PABCSystem, постольку поскольку соблюдается план, строго предписанный Issue на GitHub (для PABCSystem не имеется подобной чёткой зависимости между Issue и внесениями изменений в исходный код, что даёт некую свободу действий разработчикам, но отслеживать модификации кода становится сложнее). Взамен я получаю возможность полного контроля над процессом внедрения нового функционала и могу конкретно узнать что и когда было изменено и добавлено, аналогично, это могут сделать и сами пользователи. Другой вопрос в том, что пока нет точно установленных правил, гарантирующих, что в каждой версии будет исправляться какой-то определённый процент ошибок, добавляться новый функционал. Точнее - я могу в каждой версии исправлять и добавлять сколько хочу и чего хочу, разумеется, заранее определившись. Но, уже занимаюсь данной проблемой, чтобы достичь полной детерменированности, и чтобы избежать лишней критики от пользователей в плане: «Почему версия x исправляет n ошибок, а версия m - y?».
Предлагаю обсудить способ переиспользования предыдущих значений параметров для методов NETSquirrel. Допустим, мы желаем создать два массива с указанной длинной, но не хотим прописывать длину и другие параметры два раза. Возможный вариант реализации посредством использования nullable-типов (так уже сделано в отношении PrintSeparator):
var a := ArraysUtils.CreateRandomIntArray(223, 12, 9912);
var b := ArraysUtils.CreateRandomIntArray(nil, nil, nil);
Точнее, если требуется использования значение некоторого параметра от предыдущего вызова метода - прописываем null (nil).
Плюсы реализации:
Минусы:
Возможные проблемы:
null (nil): public static T[] GenerateArray<T>(int count, Func<int, T> selector, int firstIndex = 0). Параметр: selector. С другой стороны, можно сломать обратную совместимость и при null (nil) использовать значение от предыдущего вызова метода, вместо выброса исключения ArgumentNullException. Но, проблема будет возникать только в коде, который надеется на выброс исключения при selector == null.У кого и какие имеются рекомендации по улучшению планируемой системы сохранения значений параметров методов (@RAlex, @Admin, @ibond)? Спрашиваю вас, поскольку у вас имеется большой жизненный опыт, что важно для ответа на вопрос: Насколько полезно было бы иметь такую возможность, например, при написании учебных программ?
По-моему писать nil методически неверно. В паскале nil - синоним “ничего, пусто”. А Вы предлагаете его использовать в семантике “не изменять последнее значение”. Понимаю, почему: можно указать целочисленное значение или nil, целочисленное будет воспринято, как новое, поэтому Вы выбрали nil. Но сами отметили, что бывают ситуации, требующие именно значения nil, тут же вбивая гвоздь в крышку гроба своей идеи. Поэтому, если параметров много - делайте params и сохраняйте эти списки в матрице. Надо немножко поменять - меняете соответствующие элементы.
Ещё вариант - ввести мелкие дополнительные классы или записи для хранения информации о значениях параматров с возможностью их преобразования в кортежи для более краткой записи, ровно так же как и сделано со срезами, пример возможной реализации:
var info: ArrayGenerationInfo := (10, 10, 100); // length, low border, high border
ArraysUtils.CreateRandomIntArray(info);
Мы помним, что максимальная длина кортежа - 7 ?
Я давно тебе предлагал ввести класс, содержащий опции, как например у Process.Start есть класс с опциями ProcessStartInfo. И если таковой не передан, использовать стандартный.
Параметров у методов больше 7-ми нет и не планируется создавать подобных «монстров».
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021