Ошибки компилятора PascalABC.Net

Среда PascalABC.NET
#42

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 лайк
#43

22 сообщения перенесены в тему Болталка PascalABC.NET

#44
#45
#46

И что? Как это мешает?

#47

Причину почему это лучше запретить я указал в Issue. Также, хочу заметить, что:

Если Вы планируйте это исправить, не сейчас, а потом, то, прошу переоткрыть Issue, хотя бы по той причине, что открытая Issue будет о себе напоминать и Вы о ней не забудете.

, точнее смысл таков, что решать все-равно разработчикам.

#48

Разработчики сказали - нет. Я с ними согласен.

#49

В одном из сообщений @Admin сказал:

Впоследствии может быть расширю, а пока так.

, поэтому я и написал, что лучше оставить Issue, если они вдруг будут это исправлять. Следующее сообщение было:

Мы не планируем это исправлять.

, что однозначно отражало отрицательное мнение по поводу моёго предложения. В общем, снимаю вопрос.

Все-же, ради интереса, хотел бы узнать почему Вы с ними согласны?

#51

Потому что размерные типы активно используются и ограничения, связанные с ними могут сильно осложнить работу, сделать код нечитабельным и, что самое главное, неэффективным. Если во всём следовать C#, язык будет безвозвратно испорчен.

#52

Возможно, есть и другие примеры аналогичного поведения языков, как у C#, но это не в области моей компетенции. Если Вы таковые знайте, то было бы интересно на них взглянуть.

Хотелось бы конкретный пример кодом, доказывающим, что введение ограничение предлагаемого в Issue может сделать код неэффективным. На любом языке, на котором Вам удобно.

1 лайк
#53
#54

Я так с ходу не могу дать пример, но уверен - как только это запретят, сразу появится куча вопросов и примеров :slight_smile: Так было с sealed abstract в своё время.

#55

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

Т.е. шаблонность им закладывается еще на этапе проектирования/прототипирования, но реализация этого шаблона происходит не сразу, а постепенно (напр., начиная с простейшего или наиболее часто используемого в алгоритме размерного типа), что не позволяет ему заранее точно описать такое ограничение через интерфейс или класс, но явно указывает самому себе на необходимость уточнения этого тип-а/ов в будущем.

Это аналогично модели разработки “снизу-вверх”: сначала создается минимальный костяк (корректно компилируемый), который затем постепенно функционально расширяется.

2 лайка
#56

Все гораздо проще. Чтобы пересчитать количество разработчиков, пальцев даже на одной руке много. И они занимаются проектом, как уже подчеркивалось неоднократно, в свободное от работы время, коего у них весьма мало. Плюс, изначально не ставилась задача “догоним и перегоним С++, С# и Python в одном флаконе, взяв Паскаль за основу”. Язык уже огромен. Продолжать его расширять - это рисковать потерять контроль над проектом в целом, когда уже забываешь, зачем сделано то или это. Проекту скоро десять лет, а версии, которую можно описать так, чтобы там было всё-все, до сих пор нет. И не будет, если постоянно заморачиваться тем, чтО еще “кому-нибудь когда-нибудь может быть где-то” понадобится.

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

#57

С ними было много вопросов изначально, к примеру «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.

image
image942×194 14 KB

Согласен с мнением @ibond.

#59

Вы, разумеется, правы в том, что разработка проекта таким малым составом разработчиков - большая для них нагрузка. Но, все - же, не стоит забывать, что мнение и желание пользователей по улучшению среды и компилятора - важная вещь. Одно дело, если пользователь ничего не помогает искать из ошибок, а только предлагает улучшения, другое - когда он занимается и тем и другим. Те кто активно тестирует проект среди нас придерживается второй позиции. Конечно, хотелось бы больше тестировщиков, но, все - же, можно довольствоваться тем, что есть. Возможно, у Вас есть предложения по поводу привлечения тестировщиков в проект PascalABC.Net. Если да, то хотелось бы их услышать.

Язык нельзя описать хотя бы потому, что у него нет стандарта на данный момент.

На счёт рисков хочется сказать, что они есть всегда, особенно в разработке больших проектов.

Стоит заметить, что тема поднятого Вами вопроса с темой обсуждения про ограничения не коррелирует. Поэтому не может являться аргументом в контексте данной темы. Так, по поводу любого предложения можно упоминать эту проблему…

1 лайк
#60

Вполне реальная ситуация.

1 лайк
#61

Вы правы, по поводу любого внесения изменений в существующий проект, не являющихся ошибкой. Пока я по-прежнему вижу, что наиболее частый аргумент не конкретная нужда, а “посмотрите, вот так сделано в C#”.

1 лайк
#62

Лично я кроме ссылки на C# часто говорю почему именно я считаю, что так сделать будет лучше. Да, C# тут часто упоминается. Но, ничего нет плохого в этом. Никто не был бы против также часто слышать и про Фортран здесь (Вы точно не были бы против :wink: ). Или про любой другой язык.

#63

Я категорически против тащить сюда что-то из Фортрана. Разве только общий принцип тех же многомерных срезов, но их уже и так утащили в Питон, на который разработчики тоже делают оглядку. А так - за меня уже все сказал классик:

В одну телегу впречь не можно
Коня - и трепетную лань