Замечу, что пространства имён ещё не готовы, официально их ещё не объявляли. Так что куча issue может привести к исключению их из релиза, а это ведь не очень хорошо 
Пишите в Issue. То, что это недокументированная пока возможность, не значит, что не надо писать явные баги
2 лайка
<личное мнение>Не очень, так как я активно использую namespace’ы. Думаю, что я не единственный такой.</личное мнение>
Вы и вправду не единственный. Я их использую, но боюсь за то, что поток сообщений об ошибках может привести к их исключению из релиза, как это произошло с тайпклассами.
CRT это модуль на пару сотен строчек, все его методы можно легко реализовать самому (большая часть уже готовые в System.Console).
Ну вот смотрите, зажимаем Ctrl и нажимаем на TextColor в редакторе, видим следующее:
procedure TextColor(c: integer);
begin
Console.ForegroundColor := IntToConsoleColor(c);
end;
Значит на PABC.Net это будет выглядеть так:
//uses CRT;
begin
System.Console.ForegroundColor := System.ConsoleColor.White;
end.
Можно написать в начале программы uses System чтоб не писать его везде, то есть без него будет Console.ForegroundColor и т.п.
1 лайк
И что? Как это мешает?
Причину почему это лучше запретить я указал в Issue. Также, хочу заметить, что:
Если Вы планируйте это исправить, не сейчас, а потом, то, прошу переоткрыть Issue, хотя бы по той причине, что открытая Issue будет о себе напоминать и Вы о ней не забудете.
, точнее смысл таков, что решать все-равно разработчикам.
Разработчики сказали - нет. Я с ними согласен.
В одном из сообщений @Admin сказал:
Впоследствии может быть расширю, а пока так.
, поэтому я и написал, что лучше оставить Issue, если они вдруг будут это исправлять. Следующее сообщение было:
Мы не планируем это исправлять.
, что однозначно отражало отрицательное мнение по поводу моёго предложения. В общем, снимаю вопрос.
Все-же, ради интереса, хотел бы узнать почему Вы с ними согласны?
Потому что размерные типы активно используются и ограничения, связанные с ними могут сильно осложнить работу, сделать код нечитабельным и, что самое главное, неэффективным. Если во всём следовать C#, язык будет безвозвратно испорчен.
Возможно, есть и другие примеры аналогичного поведения языков, как у C#, но это не в области моей компетенции. Если Вы таковые знайте, то было бы интересно на них взглянуть.
Хотелось бы конкретный пример кодом, доказывающим, что введение ограничение предлагаемого в Issue может сделать код неэффективным. На любом языке, на котором Вам удобно.
1 лайк
Я так с ходу не могу дать пример, но уверен - как только это запретят, сразу появится куча вопросов и примеров Так было с sealed abstract в своё время.
Вангую: имелось в виду, что у гипотетического программиста в его конкретной программе не сразу может появиться необходимость в реализации более широкого ограничения в его шаблонной подпрограмме, но при этом уже может быть четкое понимание, что это придется сделать в последующем.
Т.е. шаблонность им закладывается еще на этапе проектирования/прототипирования, но реализация этого шаблона происходит не сразу, а постепенно (напр., начиная с простейшего или наиболее часто используемого в алгоритме размерного типа), что не позволяет ему заранее точно описать такое ограничение через интерфейс или класс, но явно указывает самому себе на необходимость уточнения этого тип-а/ов в будущем.
Это аналогично модели разработки “снизу-вверх”: сначала создается минимальный костяк (корректно компилируемый), который затем постепенно функционально расширяется.
2 лайка
Все гораздо проще. Чтобы пересчитать количество разработчиков, пальцев даже на одной руке много. И они занимаются проектом, как уже подчеркивалось неоднократно, в свободное от работы время, коего у них весьма мало. Плюс, изначально не ставилась задача “догоним и перегоним С++, С# и Python в одном флаконе, взяв Паскаль за основу”. Язык уже огромен. Продолжать его расширять - это рисковать потерять контроль над проектом в целом, когда уже забываешь, зачем сделано то или это. Проекту скоро десять лет, а версии, которую можно описать так, чтобы там было всё-все, до сих пор нет. И не будет, если постоянно заморачиваться тем, чтО еще “кому-нибудь когда-нибудь может быть где-то” понадобится.
Идеями можно фонтанировать бесконечно, особенно когда их должны реализовывать другие.
С ними было много вопросов изначально, к примеру «abstract interface» (рассматриваю сейчас эти два модификатора раздельно). Запретили, на один вопрос стало меньше. Подумайте, все - же, над примером кода. Хотя бы, чтобы доказать свою точку зрения. Впрочем, Вы сами знайте, что код обладает великой силой - доказывать сказанное.
В отношении sealed abstract классов хочу заметить, что запрет был вполне обоснован: такая запись не очень говорящая, одна из первых ассоциаций, приходящих при взгляде на эти модификаторы класса - класс и запечатан и абстрактен одновременно. Но, если следовать это логике, то возникает противоречие: наследоваться от запечатанного класса невозможно, а значит (так как класс абстрактен) никто не может реализовать его функционал. Даже если это означает совсем другое, нежели выше приведенная одна из возможных интерпретаций, то это выглядит по меньшей мере странно, так как не вызывает требуемые ассоциации (что sealed abstract - статический класс) у программиста. В качестве примера кода (как не надо делать):
namespace Test
{
public abstract sealed class T
{
}
class Program
{
public static void Main(string[] args)
{
}
}
}
, который выдаст ошибку компиляции:
“Test.T”: абстрактный класс не может иметь тип sealed или static (CS0418) - C:\Users\Admin\Documents\SharpDevelop Projects\Test1\Test1\Program.cs:13,31
Код на VisualBasic.Net:
Module Program
MustInherit NotInheritable Class T // MustInherit == abstract, NotInheritable == sealed
End Class
Sub Main()
End Sub
End Module
также выдаст ошибку компиляции:
“MustInherit” и “NotInheritable” не могут использоваться вместе. (BC31408) - C:\Users\Admin\Documents\SharpDevelop Projects\VisualBasicTest\VisualBasicTest\Program.vb:10,2
Ссылки: MustInherit и NotInheritable.
Согласен с мнением @ibond.
Вы, разумеется, правы в том, что разработка проекта таким малым составом разработчиков - большая для них нагрузка. Но, все - же, не стоит забывать, что мнение и желание пользователей по улучшению среды и компилятора - важная вещь. Одно дело, если пользователь ничего не помогает искать из ошибок, а только предлагает улучшения, другое - когда он занимается и тем и другим. Те кто активно тестирует проект среди нас придерживается второй позиции. Конечно, хотелось бы больше тестировщиков, но, все - же, можно довольствоваться тем, что есть. Возможно, у Вас есть предложения по поводу привлечения тестировщиков в проект PascalABC.Net. Если да, то хотелось бы их услышать.
Язык нельзя описать хотя бы потому, что у него нет стандарта на данный момент.
На счёт рисков хочется сказать, что они есть всегда, особенно в разработке больших проектов.
Стоит заметить, что тема поднятого Вами вопроса с темой обсуждения про ограничения не коррелирует. Поэтому не может являться аргументом в контексте данной темы. Так, по поводу любого предложения можно упоминать эту проблему…
1 лайк
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021