Мощная среда ZXDev для разработки НА ПЯТИ ЯЗЫКАХ для ZX готова к тестированию

[s_kosorev]

реализация абстрактных интерфейсов

мх.. станное понятие абстрактный интерфейс, есть понятие интерфейс, синоним абстрактноного класса.
Но! реальная польза от него появляется при наличии множественного наследования, речь не о множественном наследовании реализации как в с++ а именно множественное наследование интерфейсов

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

Т.е. нет сложного момента как множественного наследования поведения, но в тоже время, могу описывать классу разное поведение, причем не кучу поведения от сложного супер класса, а разного рода мелкие поведеня

- - - Добавлено - - -

в zonnon такое поведение реализовано, но мотив скорее всего, что бы можно было нормально .net библиотеку юзать

[Oleg N. Cher]

ОК, предположим, я неверно выразился.

Абстрактный интерфейс — т.е. оторванный от реализации. Может иметь одну или несколько реализаций. "Класс" говорим по аналогии, потому-что в Обероне это всё-таки запись (RECORD). Поэтому я говорю не "класс", а "интерфейс" [модуля]. Можно "абстрактная запись".

• Что такое компонентно-ориентированное программирование (краткая справка)
  

  Можно сказать, что КОП — это такое ООП, которое подчинено требованиям безопасности "старого" структурного и модульного программирования примерно в том виде, в каком эти требования были реализованы в классической Модуле-2 (в отличие от языков типа Smalltalk, в которых ООП является основным механизмом, который применяется без ограничений).
  
  Краткое обсуждение компонентно-ориентированного программирования дано в http://www.oberon.ch/resources/compo...tware/cop.html (эту статью надо бы перевести на русский язык). Из статьи следует примерно такая формула для КОП:
  
  КОП = ООП
  
  + модульность (включая упрятывание информации и позднее связывание модулей, т.е. возможность подгружать необходимые модули в процессе выполнения программы, а не заранее, как это обычно делается в старых системах программирования)
  
  + безопасность (статический контроль типов переменных и автоматическое управление памятью)
  
  - наследование реализации через границы модулей.
  
  Последняя строчка означает, что в КОП запрещено наследование от типов, реализованных в других модулях; наследовать можно только абстрактным, чисто интерфейсным типам (помеченных атрибутом ABSTRACT в Компонентном Паскале).
  
  Между прочим, Оберон-2 не удовлетворяет в полной мере требованиям КОП: в нём любой тип может быть расширен. Это делает программы, написанные на нём, уязвимыми для проблемы хрупких базовых классов. Именно для устранения этой "дыры" в системе безопасности Оберона-2 и были в первую очередь предприняты модификации языка, реализованные в Компонентном Паскале.
  
  В классическом Обероне тоже можно расширять любой тип, но там нет методов, так что и проблема менее остра.

• https://ru.wikipedia.org/wiki/Компонентно-ориентированное_программи� �ование

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

[Oleg N. Cher]

Новости по проекту.

1. ZXDev окончательно решено перевести на z88dk-SDCC. Это придаст ему ряд дополнительных возможностей, особенно в плане использования z88dk’шных библиотек (Hello, Alcoholics Anonymous!).

2. Раз уж все разобрались, чем отличается Компонентный Паскаль от Оберона-2, сообщаю, что мне удалось достать фирменный транслятор КП-в-Си от Oberon microsystems (на базе Ofront’а), и теперь основным языком разработки в XDev будет Компонентный Паскаль. Оберон-2 также будет в списке поддерживаемых языков.

Разумеется, это не настолько важно именно для ZXDev — для Z80 Оберон-2 будет даже предпочтительнее, ибо в КП фиксированная арифметика (все вычисления производятся в 32 бит/64 бит, и потом только приводятся к требуемому типу), т.е. на О2 складывание чисел типа SHORTINT — задача вполне в рамках SHORTINT. КП же считает, что возможно переполнение и требуется бОльшая разрядность. Поэтому результат — типа INTEGER, и уже потом приводится к SHORTINT, если требуется.

3. Сообщаю, что от души наигрался с компиляторами типа tcc/DJGPP и теперь окончательно перевожу WinDev на GCC/MinGW. GCC тоже умеет делать компактные exe/dll (для этого следует использовать свой crt1) — и Hello World получается 1,5 кб. На сегодняшний день в WinDev есть биндинги к WinApi, SDL, SDL 2, LibC. Можно успешно делать проекты типа небольших утилит. Пример сделанного в WinDev:

• Утилитка для исправления имён файлов в кодировках UTF-8 и Hex

• Часики как пример порта с ADW Modula-2 на XDev Oberon

С этими изменениями XDev начинает приобретать качества промышленного продукта, хотя ему по-прежнему очень не хватает систематичного подхода к разработке. Просто много рутины, которая делается в “ленивом” режиме по мере надобности.

4. XDev для Linux. Может быть получен на основе Freenix, вышеупомянутого транслятора КП-в-Си и GCC. С помощью подсистемы Master будет доступна раскраска синтаксиса. Толковый программист при соответствующей мотивации собрал бы всё это воедино за очень небольшой срок. Проблема с мотивацией — мне вполне хватает XDev для Windows. К тому же я взялся и так за слишком большой проект, и мэйнтейнить две версии, вторая из которых мне напрямую не нужна, представляется излишней роскошью. Но всё возможно, требуются лишь энтузиасты, чтобы продвигать это направление.

[Oleg N. Cher]

.NET Native compiles C# to native machine code that performs like C++. Windows 10 Universal applications built with C# or VB are optimized with .NET Native. With .NET Native optimization, apps start up to 60% faster and use 15-20% less memory when compiled with .NET Native.

https://msdn.microsoft.com/en-us/vst...netnative.aspx

У меня вопрос к дотнетоведам. Риторический. Если у технологии .NET всё так замечательно, то какой смысл в такого рода приблудках как эта? Сначала создали себе сложность в виде VM, но потом её героически преодолели?

[s_kosorev]

Сначала создали себе сложность в виде VM

VM у явы, дотнет с рождения JIT

.net native для игрушек и телефонов, там где побочка управляемого кода особенно заметна, производительность транслированного и обычного приложения в среднем одинакова, но для PC лишние 20Ватт энергии и лишние 20% обычно незаметны

[Alex Rider]

Если у технологии .NET всё так замечательно, то какой смысл в такого рода приблудках как эта?

Сделать побыстрее запуск на медленных устройствах. Кроссплатформенность бинарника при этом теряется, но остальные фишки .NET - безопасность кода и, собственно, библиотека классов остаются. Исходный код также остается кроссплатформенным.

[Oleg N. Cher]

Насколько я понимаю, безопасность кода и натив аж никак не мешают друг другу существовать вместе. И для этого не нужны никакие VM.

Исходный же код - не кросс, а именно моноплатформенный (.NET only), и никак иначе. Да, это можно сэмулировать на других платформах, но толстым способом.

[Alex Rider]

Насколько я понимаю, безопасность кода и натив аж никак не мешают друг другу существовать вместе. И для этого не нужны никакие VM.

Правильно. VM нужны для кроссплатформенности (целевой) на этапе исполнения. .NET помимо этого дает еще много плюшек, например, безопасность, библиотеки, многоязычность, популярность (в частности, довольно мощное комьюнити). .NET Native отбирает у скомилированного бинаря только целевую кроссплатформенность, оставляя все остальные плюшки. Это неплохо.

Исходный же код - не кросс, а именно моноплатформенный (.NET only), и никак иначе. Да, это можно сэмулировать на других платформах, но толстым способом.

Олег, с тобой бесполезно спорить. Не выставляй себя недалеким - ты же прекрасно знаешь, что не существует платформы .NET, и что сборки .NET не эмулируются, правда?

[s_kosorev]

CoreCLR, уже работает на маках, линухах итд, от MS

Можно сказать это еще один Mono но от MS

[Eltaron]

Если у технологии .NET всё так замечательно

А именно это и не замечательно. JIT-компилятор в дотнете слабый и тупой. Вот, скажем, 10 лет назад все плевались и от Java-, и от .NET-экзешников, когда они стартовали целую минуту и еле ворочались. Сейчас джава это практически полностью преодолела за счет крутого интеллектуального JIT. Дотнет же как тормозил при старте, так и тормозит. Просто на современном железе это однократное торможение при первом запуске практически незаметно, а вот на задачах, для которых создан .NET Native, разница, видимо, есть.