Автор Тема: Добавить методы в О7/13  (Прочитано 35996 раз)

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Добавить методы в О7/13
« : Ноябрь 13, 2013, 03:26:16 am »
Буду пробовать добавить методы в текущую реализацию. Предлагаю пообсуждать - кто в каком виде их хочет видеть.
Примерные вопросы:
- виртуальность (всегда или могут быть невиртуальные методы)
- абстрактные методы (можно попробовать без них)
- интерфейсы (возможно стоит отделить чисто методы от чисто данных)
- синтаксис (где объявлять - в TYPE или потом вместе с остальными процедурами)

За основу можно взять проверенное решение из ББ.

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Добавить методы в О7/13
« Ответ #1 : Ноябрь 13, 2013, 03:38:00 am »
За основу можно взять проверенное решение из ББ.

ProcedureHeading   = PROCEDURE [Receiver] IdentDef [FormalParameters] MethAttributes.
Receiver    = "(" [VAR | IN] ident ":" ident ")".
MethAttributes   = ["," NEW] ["," (ABSTRACT | EMPTY | EXTENSIBLE)].


Интересен тут Receiver, который может быть как POINTER так и ссылкой на переменную. Это, как я понимаю, дает возможность "запретить" вызов каких-то методов для объектов, не полученных через NEW.

С другой стороны мне не нравится явная спецификация this/self. Оно конечно показательно при обучении, но вот мусора (синтаксического) и беспорядка (кто как хочет так и называет) больше. Т.е., в этом вопросе я однозначно за дополнительное ключевое слово this/self. Хотя в моем синтаксически любимом питоне self тоже явный :)

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Добавить методы в О7/13
« Ответ #2 : Ноябрь 13, 2013, 04:24:36 am »
Да, решаемая задача формулируется так: подменить реализацию в случаях, когда подменить модуль (основное средство сокрытия реализации в Обероне) невозможно/неудобно. Поэтому любые альтернативные предложения, включая, например простую подмену модулей (не могу представить как это может выглядеть, но вдруг) - также принимаются.

Предлагаемый Виртом вариант инсталляции процедур в поля рекордов на общее/надежное/простое решение никак не тянет.

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Добавить методы в О7/13
« Ответ #3 : Ноябрь 13, 2013, 04:51:03 am »
Ну и первый набросок:
TYPE
    Interface1* = INTERFACE
        method1();
        method2(i: INTEGER): CHAR;
    END;
    PInterface1* = POINTER TO Interface1;

    Interface2* = INTERFACE(Interface1)
        method3();
    END;

    Interface3* = INTERFACE
        method4();
    END;

    R1 = RECORD(Interface1)
        i: INTGER
    END;

    R2 = RECORD(R1, Interface3)
        c: CHAR
    END;

PROCEDURE R1.method1();
BEGIN
    this.i := 123;
END R1.method1;

PROCEDURE R2.method1();
BEGIN
    this.method1^();
    this.c := "a";
END R2.method1;

PROCEDURE make1*(): PInterface1;
VAR
    result: POINTER TO R1;
BEGIN
    NEW(result);
    RETURN result
END make1;

PROCEDURE make2*(): PInterface1;
VAR
    result: POINTER TO R2;
BEGIN
    NEW(result);
    RETURN result
END make1;

- интерфейсы можно наследовать (множественно)
- записи наследуют интерфейсы (множественно)
- интерфейс нельзя создать ни через NEW ни как переменную
- правила экспорта, приваивания, приведения типа - можно обсудить (вроде ничего сильно спорного пока не возникает).

Добавились ключевые слова INTERFACE и this. Но зато не нужен (вроде) весь арсенал из ББ - ABSTRACT, NEW.

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Добавить методы в О7/13
« Ответ #4 : Ноябрь 13, 2013, 05:19:22 am »
Вапще я часто встречаю мнение, что интерфейсов достаточно, так что процедуры, привязанные к записям (как в обероне-2 и кп) нинужны.
В принципе, интерфейсы имеют сходство с классами типов хаскелла, так что я за них.
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: Добавить методы в О7/13
« Ответ #5 : Ноябрь 13, 2013, 08:22:07 am »
Мне кажется, что нужно отталкиваться от конкретных задач.

Т.е. добавляемая фича должна быть решением конкретной проблемы. Иначе фигня получится.

ps Сейчас натягиваю rbtree на CP. Подводные камни в самых неожиданных местах всплывают.
« Последнее редактирование: Ноябрь 13, 2013, 08:24:16 am от ilovb »

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: Добавить методы в О7/13
« Ответ #6 : Ноябрь 13, 2013, 08:47:41 am »
Немного разверну мысль:
имхо
Чтобы получить качественный результат нужно:
1. Сформулировать задачу
2. Попытаться решить задачу на O13 (разными путями)
3. Если решить не удалось или решение неудовлетворительное, то определить причину.
4. Если причина ясна, то предложить фичу
5. Если фича действительно дает профит при решении данной задачи/класса задач, то можно подумать о включении ее в язык.

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Добавить методы в О7/13
« Ответ #7 : Ноябрь 13, 2013, 10:00:08 am »
Немного разверну мысль:
имхо
Чтобы получить качественный результат нужно:
1. Сформулировать задачу
2. Попытаться решить задачу на O13 (разными путями)
3. Если решить не удалось или решение неудовлетворительное, то определить причину.
4. Если причина ясна, то предложить фичу
5. Если фича действительно дает профит при решении данной задачи/класса задач, то можно подумать о включении ее в язык.

Причем не стоит забывать и о внеязыковых методах решения проблемы.

Пример - ключевые слова КАПСОм в языке набирать не удобно (мне по крайней мере) пальцы уставать начинают. Можно поменять язык, а можно написать плагин к текстовому редактору, который это будет делать за тебя. Что я и сделал. Теперь КАПС в языке проблем не вызывает.
Y = λf.(λx.f (x x)) (λx.f (x x))

adva

  • Sr. Member
  • ****
  • Сообщений: 385
    • Просмотр профиля
Re: Добавить методы в О7/13
« Ответ #8 : Ноябрь 13, 2013, 01:22:51 pm »
Не совсем догоняю, а с ключевым словом ИНТЕРФЕС и звездочки не нужны будут?

Пока ничего определенного, по этому высказать не могу, кроме того, что было бы удобнее чем без этого даже как в КП (или именно так). Наследование интерфейсов будет только из текущего модуля, или других тоже?

Вроде удобство, но с другой стороны, чем то мне это напоминает типизацию/без типизации, только на другом уровне. Поэтому я пока за одиночное наследование (или как оно там называется)

adva

  • Sr. Member
  • ****
  • Сообщений: 385
    • Просмотр профиля
Re: Добавить методы в О7/13
« Ответ #9 : Ноябрь 13, 2013, 01:30:32 pm »
А все расширизмы выльются в одну опцию компилятора, или в несколько (ну по крайней мере как задумывается :) )?

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Добавить методы в О7/13
« Ответ #10 : Ноябрь 13, 2013, 03:09:46 pm »
Мне кажется, что нужно отталкиваться от конкретных задач.
Т.е. добавляемая фича должна быть решением конкретной проблемы. Иначе фигня получится.

Безусловно. Задача сформулирована здесь: http://oberspace.dyndns.org/index.php/topic,579.msg19580.html#msg19580
Еще более конкретно - думаю как на обероне будет выглядеть вот это: https://github.com/vladfolts/oberonjs/blob/master/src/type.js

ps Сейчас натягиваю rbtree на CP. Подводные камни в самых неожиданных местах всплывают.

Дык, поделись ;)

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Добавить методы в О7/13
« Ответ #11 : Ноябрь 13, 2013, 03:17:41 pm »
2. Попытаться решить задачу на O13 (разными путями)

В данном случае решение на О7/13 (подстановка процедурных переменных) хорошо проработано (и описано самим Виртом). И оно неудовлетворительно. Могу расписать все недостатки, но они очевидны для любого, кто эмулировал это на О7 и может сравнить с тем, как это делается в языке с непосредственной поддержкой ООП.

3. Если решить не удалось или решение неудовлетворительное, то определить причину.

Причина тоже очевидна - нехватка выразительных средств языка.

4. Если причина ясна, то предложить фичу
5. Если фича действительно дает профит при решении данной задачи/класса задач, то можно подумать о включении ее в язык.

Фича предложена, давайте подумаем ;)

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Добавить методы в О7/13
« Ответ #12 : Ноябрь 13, 2013, 03:21:26 pm »
Пример - ключевые слова КАПСОм в языке набирать не удобно (мне по крайней мере) пальцы уставать начинают. Можно поменять язык, а можно написать плагин к текстовому редактору, который это будет делать за тебя. Что я и сделал. Теперь КАПС в языке проблем не вызывает.

На самом деле вызывает :) Потому что буков все равно много. Просто хотя бы набирать проще. Какое внеязыковое средство ты предлагаешь для этой проблемы?

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Добавить методы в О7/13
« Ответ #13 : Ноябрь 13, 2013, 03:24:35 pm »
Пример - ключевые слова КАПСОм в языке набирать не удобно (мне по крайней мере) пальцы уставать начинают. Можно поменять язык, а можно написать плагин к текстовому редактору, который это будет делать за тебя. Что я и сделал. Теперь КАПС в языке проблем не вызывает.

На самом деле вызывает :) Потому что буков все равно много. Просто хотя бы набирать проще. Какое внеязыковое средство ты предлагаешь для этой проблемы?
Автокомплит конечно! :-) Алсо число букв не зависит от того капс это или не капс :-)
Y = λf.(λx.f (x x)) (λx.f (x x))

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Добавить методы в О7/13
« Ответ #14 : Ноябрь 13, 2013, 03:35:13 pm »
Не совсем догоняю, а с ключевым словом ИНТЕРФЕС и звездочки не нужны будут?

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

Пока ничего определенного, по этому высказать не могу, кроме того, что было бы удобнее чем без этого даже как в КП (или именно так). Наследование интерфейсов будет только из текущего модуля, или других тоже?

Да, конечно. Это основная идея. Реализовать экспортированный интерфейс может кто угодно. Расширяем систему не только подменой модулей.

Вроде удобство, но с другой стороны, чем то мне это напоминает типизацию/без типизации, только на другом уровне. Поэтому я пока за одиночное наследование (или как оно там называется)

Про множественное наследование уже несколько раз обсуждали. Не вижу смысла запрещать его конкретно для интерфейсов.