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

Среда PascalABC.NET
#64

Много куда делается оглядка при разработке PascalABC.Net. Кстати, Issue про срезы матриц все также висит… Может, поднять эту тему здесь на форуме? Я уже там отразил своё мнение, пора бы услышать мнение и других.

#65

Но есть иерархия. Прежде всего - Дельфи, FPC (они тоже Паскаль). Потом уже все остальное.

Да. Мне разработчики объяснили проблемы, которые возникают в связи с этим. Поэтому я не считаю для себе приемлемым снова раскачивать этот больной зуб. Помимо форума, у меня есть дополнительный, менее формальный канал канал общения, поэтому я временами выступаю с заявлениями, которые могут быть схожи с позицией разработчиков, хоть и не озвучивались тут.

#66

Хорошо, не буду поднимать эту тему. Если кто-то все-таки решится, пусть это сделает (если захочет).

Можно с этого места поподробнее?

#67

Нельзя. Если бы разработчики хотели что-то публично озвучить, они бы это сделали.

#68

В таком случае побеседую через личные сообщения с разработчиками. Разумеется, выносить на общее обозрение сказанное ими я не буду.

#69

Это правильное решение.Если посмотрите, я даже issure не пишу, хотя ошибки тоже иногда выявляю. Особенно, когда на самом деле они не являются ошибками. Часто проще сначала обсудить в личной беседе, чем писать пр принципу “А не понравится - удалят”…Но, повторюсь, это лишь мое личное мнение, я никому его не навязываю в качестве мерила поведения.

1 лайк
#71
#72

Хотел бы только заметить, что при прочих равных, ссылка на “так УЖЕ где-то работает и это очень удобно/эффективно” гораздо более весомый аргумент в защиту своего предложения расширять удобство и функционал языка, чем ссылка на “посмотрите, так НЕ работает/ НЕ принято там-то или там-то” в защиту своей идеи с целью ограничивать уже работающий функционал.

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

1 лайк
#73

Если что-то работает, и работает правильно, смысл удалять? Но только работает не где-то, а в конкретной реализации, о которой речь. Если это PascalABC.NЕТ и в нем что-то уже работает, так это никто и не удаляет от нечего делать. А если это работает в каком-то другом языке, то пусть там и работает дальше.

1 лайк
#74

Так и я об этом же!

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

Другое дело, что тут надо взвешивать и все прочие факторы – реальную потребность целевой аудитории, сложность реализации и поддержки, дублирование возможностей, особенности синтаксиса и родной платформы, и прочее.

Но сходу все отвергать без должного анализа – тоже неправильно.

#75

Можно рассмотреть фактор обратной совместимости. Возможно, что это где-то уже использовалось, и, возможно, именно поэтому разработчики отказываются рассмотреть этот вопрос. Если это так, то у меня больше вопросов нет. Но использовалось ли это реально - вопрос другой. Ответ получить на него весьма сложно. Это еще раз хороший пример, что не надо забывать про этот фактор. Впрочем, этот недостаток, на мой взгляд, не так уж и велик. Хотя, можно вспомнить, что вердикт о профессиональности ПО выносится на основе совокупности мелочей, но, разработчики огласили своё решение, думаю, что давить на них не стоит.

Но, все-же, очень интересно посмотреть на код, который приведет (я очень надеюсь) @Gleb в виде доказательства реальной полезности этой возможности.

Впрочем, беседа по поводу ограничений, никак не мешает фокусироваться на проблемах форматирования и Nullable<T>, например.

Чтобы не спорить бесконечно, создам опрос:

Запретить ли размерные типы в качестве ограничения?

  • Да
  • Нет
  • Нейтральная позиция

0 голосов

, посмотрим на решение большинства.

#76

Если многие не хотят прямой, то об обратной и речи быть не может.

Да хоть Ваш код и взять. Допустим, структуры в ограничителе были запрещены. Для передачи byte, его нужно будет упаковать в object, а в методе проверять, собственно, чтобы в object лежал именно byte. Как итог - низкая производительность (boxing/unboxing, проверки), костыли в коде и куча потенциальных ошибок, отлов которых может затянуться на неопределённый срок.

Вот именно. Анекдот про программиста и его сына, думаю, знают все.

#77

Просто передать byte-параметр не вариант?

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

type
  TA = class
  end;
  
  TB = sealed class(TA)
  end;

procedure P1(x: TA); // TA/TB
begin
end;

procedure P2<T>(x: T); // TA/TB (Можно и так, но вариант с P1 также подходит.)
  where T: TA;
begin
end;

procedure P3<T>(x: T); // TB (Да, можно и так, но почему не как P4, так как фактически ограничение сводится к конкретному типу?)
  where T: TB;
begin
end;

procedure P4(x: TB); // TB
begin
end;

begin
end.
#78

Ну так если ограничитель не предполагает byte?

#79

Нет. Вы меня не поняли. Смысл тут ограничения использовать?

#80

Вам @RAlex и @spectatorBH уже сказали. Зачем трогать то, что никому не мешает? Или мешает только тем, что этого нет в C#? Ну так в Microsoft вопросы.

#81

Да, сказали, но Вы код не привели.

*в PascalABC.Net, в C# имеется.

#82

Про код я уже сказал выше.

#83

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

#84

Я считаю, что смысла устанавливать жёсткие параллели между PascalABC.NET и любым другим языком - глупо, т.к. просто невозможно. У каждого языка, из которого в PascalABC.NET добавляют возможности, свои особенности, очень часто противоречащие непосредственно PascalABC.NET или другим родственным языкам.