Unintrusive Retroactive Polymorphism - Философия программирования

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Потому что Херон вырос из надстройки над C++, и я не удивлюсь, если он включит в себя и более традиционные для C++ "интерфейсы", либо же вольется назад в C++ в виде части языка.

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

... << RSDN@Home 1.1.4 beta 3 rev. 273>>

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>А зачем изначально по-твоему было введено разделение на reverence- и value- типы? Скажем, в том же SmallTalk, тоже объектно-ориентированном языке, такого разделения нет. Там все типы — наследники Object.

Там и статической типизации нет. В общем, предпосылкой для введения вэлью-типов конечно являлась и производительность. Но... не только она и в обсуждаемой теме речь не о введении вэлью-типов, а о введении автоматического боксинга. Введение вэлью-тиов было сделано еще в Яве и Пасклае (ну, и в С). Шарп же попылатся (и довольно удачно) скрестить идею вэлью-типов с идеей "все — объект" из Смолтока. В итоге получается решение потенциально предоставляющее и высокую производительность, и безопасность типов (полную), и гибкость как в Смолтоке. Естественно идеал по прежденму не достигнут, но шаг к нему сделан очень значительный.

ПК>Например, передать ссылку на базовый интерфейс в функцию, чтобы она через этот интерфейс данный объект изменила.

Да, это было бы красиво. Но к сожалению это достижимо только хаком, и ребята из МС на это не пошли. Хотя если передавать не сам интерфейс а вэлью-тип и не абы куда, а в дженерик у которого есть констрэйн на этот интерфейс, то все очень даже достижима. Одна беда... в бэтах скорость такого вызова даже ниже чем у простого интерфейса (не очень качественная реализация). Но потенциально возможна полная оптимизация в продь до инлайнинга метода интерфейса. Причем сам дженерик на это никак не завязан. Рантайм сам поймет нужно ли ему создавать специализацию или можно воспользоваться динамическим полиморфизмом.

Я думаю, что будущее именно за таким подходом. В общем, пара мегабаксов в оптимизирующие компиляторы и перевод компиляции на стадию инсталляции и дело в шляпе. Мы имеем "полиморфизм без ремарок" и наивысшую скорость. Ну, а там дело за малым. Добавить автоматизацию подключения дополнительных реализаций и ввести средства метапрограммирования...

... << RSDN@Home 1.1.4 beta 3 rev. 273>>

Здравствуйте, WolfHound, Вы писали:

WH>Так value типы и есть оптимизация из-за которой понадобился боксинг...

WH>Назови хоть одну причину (кроме производительность и потребления памяти те забиваем на оптимизацию на уровне языка пусть jit все разруливает как ему хочется) по которой int не может быть ссылочным типом.

Дык Шарп ростет из Явы. В яве уже были примитивные вэлью-типы. Так что оптимизация была сделана до него. А АВК говорит о том, что ПК неврено назвал боксинг оптимизацией. Это "синтаксический сахар" цель которого воплотить идею Смолтока — "Все — объект!".

Вот только идея не доведена до логического завершения. По хорошему для боксед-объектов нужно было бы реализовать весь интерфейс забоксеного типа. Вот тогда полиморфизм был бы мама дорогая. Но тогда бы действительно было трудно понять где кончается динамическая типизация и начинается статическая. Видимо Хебельберг это понял и побоялся того что реальные решения с использовнием Шарпа окажутся слишком медленные (причем нечаяно).

ЗЫ

Ты кстати, где? Что-то тебя после перезда совсем не слышно. Заехал бы как-нибудь... рассказал бы как дела...

... << RSDN@Home 1.1.4 beta 3 rev. 273>>

Здравствуйте, c-smile, Вы писали:

CS>Про рантайм: так как interface reference (a la Heron) это
CS>пара {this, function table pointer} то на них красиво делаются

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

CS>delegates (closures) например.

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

CS>interface reference это как бы мост меж двух миров templates (static polymorph) и virtual (dynamic polymorph).

Вот как такой мост мне эта идея не нравится. АВК правильно говорит, слишком уж фича завязана на компайл-тайм.

CS>Есть такое дело со стандартами. И это наверное разумно. Не знаю.

Незнаю. Я раньше надеялся на то что С++ подправят и будет конфетка, а не язык, но теперь уже надежда ушла. Думаю проще другие средства адаптировать чем ловить тараканов в С++.

... << RSDN@Home 1.1.4 beta 3 rev. 273>>

VladD2,

> Дык Шарп ростет из Явы. В яве уже были примитивные вэлью-типы. Так что оптимизация была сделана до него. А АВК говорит о том, что ПК неврено назвал боксинг оптимизацией.

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

Posted via RSDN NNTP Server 1.9

VladD2,

> <...> Введение вэлью-тиов было сделано еще в Яве и Пасклае (ну, и в С)

Речь идет не о введении value-типов, а о разделении на value- и reference- типы. В Паскале и C такого разделения нет.

> ПК> Например, передать ссылку на базовый интерфейс в функцию, чтобы она через этот интерфейс данный объект изменила.

> Да, это было бы красиво. Но к сожалению это достижимо только хаком <...>

В Heron это делается безо всяких хаков, просто и красиво. С сохранением динамического полиморфизма для интерфейсов. Чем упрекать других в косности, лучше бы глянул повнимательнее: там по сравнению с C#/Java/whatever, действительно, оригинальная концепция реализации полиморфизма.

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

На первый взгляд пока что там и без generics скорость даже простейших абстракций типа IntWrapper не блещет.

> Я думаю, что будущее именно за таким подходом. В общем, пара мегабаксов в оптимизирующие компиляторы и перевод компиляции на стадию инсталляции и дело в шляпе. Мы имеем "полиморфизм без ремарок" и наивысшую скорость. Ну, а там дело за малым. Добавить автоматизацию подключения дополнительных реализаций и ввести средства метапрограммирования...

Ну, судя по beta 1, Нью-Васюки пока откладываются.

Posted via RSDN NNTP Server 1.9

Здравствуйте, VladD2, Вы писали:

MS>>Вопрос был о том, где обнаружится ошибка, на стадии компиляции или на стадии выполнения, если у класса X удалить метод Foo(). Ты утверждаешь, что компилятор не может это обнаружить, а будет исключение во время выполнения. Утвержение является ложным, поскольку C# заставляет явно определять все методы интерфейса при наследовании от этого интерфейса.

VD>Я уж не знаю как нужно упереться рогом, чтобы не понять, что при удалении метода нужно удалить и наследование интерфейса.

Влад, у вас с Andrew какие-то не-лады с определением причинно-следственных связей, что мне и не давало мне покоя. Если удалить наследование интерфейса, то удаляь метод уже не не нужно — он уже ни на что не влияет. В C# первичным является наследование от интерфейса (intrusive), в Хероне — наличие методов с нужными сигнатурами (unintrusive). Вот и всех делов.

Здравствуйте, c-smile, Вы писали:

Хочешь чего-нибудь такого?

class C
 {
  public:
  
   int method1();
   double method2();
 };

struct MethodMap
 {
  int (::*method1)();
  double (::*method2)();
  
  template <class T>
  explicit MethodMap(T &x)
   {
    method1 = x .* &T::method1 ;
    method2 = x .* &T::method2 ;
   }
 };

/* main() */ 

int main()
 {
  C c;
  
  MethodMap map(c);
  
  int x=map.method1();
  double y=map.method2();
 
  return 0;
 }

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, VladD2, Вы писали:

MS>>Ну и вот. "Ответ не верный. Ваше очко переходит залу"...

VD>Блин. Это не вопрос веры.

Допустил грубую граматическую ошибку, за что извиняюсь. Правильно звучит, конечно же "Ответ неверный". А вопросы "веры" здесь действительно ни при чем.

Надеюсь, не нужно объяснять разницу между понятиями "верный — неверный" и "верю — не верю"?

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Это неправильный вариант. Это удаление наследования от IA у класса Y, в то время, как [url=http://rsdn.ru/Forum/Message.aspx?mid=977486&only=1речь шла[/url] об удалении члена Foo() из класса X.

ПК>Так что еще одно очко переходит залу

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

... << RSDN@Home 1.1.4 beta 3 rev. 273>>

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>VladD2,

>> <...> Введение вэлью-тиов было сделано еще в Яве и Пасклае (ну, и в С)

ПК>Речь идет не о введении value-типов, а о разделении на value- и reference- типы. В Паскале и C такого разделения нет.

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

Этак мы до ассмеблера договоримся. Там даже типов данных как таковых нет. И что?

ПК>В Heron это делается безо всяких хаков, просто и красиво. С сохранением динамического полиморфизма для интерфейсов. Чем упрекать других в косности, лучше бы глянул повнимательнее: там по сравнению с C#/Java/whatever, действительно, оригинальная концепция реализации полиморфизма.

Я уже глянул. Там или статический полиморфизм и соотвественно не гибкость или задница со скоростью в следствии интерпретакции. И то, и то нехороший компромис. Я уже тут раза три говорил, что мне бы больше пронравилась идея втоматического устранения виртуальности компилятором. Думаю это вопрос 2-3 лет. Так что стоит ли копья ломать еще большой вопрос.

ПК>На первый взгляд пока что там и без generics скорость даже простейших абстракций типа IntWrapper не блещет.

На первый вгляд на первый взгляд там ошибки в тестах. Да и ситуация больно надуманная. Я таких задач не встречал. Скорость вызова виртуального метода раз в 6 ниже обычного (особенно при инлайнинге). Делегаты во втором фрэймворке еще где-то в 2-4 раза медленее. Итого если ты занимашся постоянными сортировками интов, то умнее просто испоьзовать ручную (или сгенерированную) реализацию. В остальных же случаях стоимость виртуального вызова не сравнима с выполняемым кодом, так что и обсуждать нечего. В реальных разницы практически не заметно. На тот же янус постоянно жалуются, но тормозит то там Jet кторый как ты понимаешь самый что ни на есть анменеджед.

Ну, и опять же если ты нарвался на узкое место которое действительно серьзено тормозит код, то никто не мешает открыть МС++ и создать на нем нужные тонко потимизированные места. Далее сделать библиотечку и юзать ее в Шарпе. За-то 99% времени наслаждаешся простотой и спокойствием обращая время только на решаемую задачу.

ПК>Ну, судя по beta 1, Нью-Васюки пока откладываются.

Да в общем, более чем нормально. Ты уперся в синтетические тесты на проблемных задачах (где кстати, на поверку все более чем зашибитьс, опять же см. мой ответ). На практике же основной код возится с морем частностей которые прекрасно оптимизируеются. Ну, и (опять повторяюсь) генерация кода плюс МС++ на крайняк спасают отцов русской демакратии.

Кстати, тот факт что лично я отказался от использования С++ в том же древесном контроле созданном для Януса, и то что более нигде я так и не применил МС++ говорит, о том, что это реально в общем то и не нужно. Но чувствовать, что всегда есть "запасная дверь" очень приятно.

... << RSDN@Home 1.1.4 beta 3 rev. 273>>

Здравствуйте, VladD2, Вы писали:

VD>Согласен. Это как раз тот случай где без динамического полиморфизма никуда.
VD>Но это только если исправить море допущенных ошибок

.

Не придирайся к мелочам.

Идея кода была понятна даже мне, чайнику в C#: http://www.rsdn.ru/Forum/Message.aspx?mid=977733&only=1 (обрати внимание на дату сообщения).
Недоумение вызвала лишь фраза об удалении метода в коде на C#, которе должно было якобы привести к ошибке времени выполнения. Это вызвало искреннее недоумение. А на самом деле оказалось, что дело совсем в другом — что надо удалять не метод, а сам интерфейс целиком, что кардинальным образом меняет структуру зависимостей. Ну сколько можно долдонить об одном и том-же?!

"Бросай ружье, да всплывай поскорей" здесь

(26K)

Здравствуйте, c-smile, Вы писали:

Интерсная и очень показательная переписка "Heron"("christopher diggins") <-> David Abrahams (boost consalting, главный meta programmer

)

здесь

David Abrahams сказал 2004-04-25 18:53:07 PST

I believe I could write macros to allow you to generate baz with:

DECLARE_INTERFACE(
baz,
((int)(foo)(int))
((int)(bar)(char const*))
);

David Abrahams еще сказал 2004-04-30 11:13:06 PST

If I get a few minutes maybe I'll hack them up for fun.

Чего-то не видать результата. Ну да и ладно

Похоже David в тумане метапрограмизма не проникся идеей которя на мой взгляд футдаментально-положительная.

Здравствуйте, Шахтер, Вы писали:

Ага

Причем сильно хочу.
Сейчас это все приходится руками делать...

Здравствуйте, c-smile, Вы писали:

CS>Интерсная и очень показательная переписка "Heron"("christopher diggins") <-> David Abrahams (boost consalting, главный meta programmer

)

CS>здесь

CS>David Abrahams сказал 2004-04-25 18:53:07 PST

CS>

CS>I believe I could write macros to allow you to generate baz with:

CS>DECLARE_INTERFACE(
CS> baz,
CS> ((int)(foo)(int))
CS> ((int)(bar)(char const*))
CS>);

CS>David Abrahams еще сказал 2004-04-30 11:13:06 PST
CS>

CS>If I get a few minutes maybe I'll hack them up for fun.

CS>Чего-то не видать результата. Ну да и ладно

CS>Похоже David в тумане метапрограмизма не проникся идеей которя на мой взгляд футдаментально-положительная.

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

Вот наброски того как это могло бы выглядеть в C++
http://www.heron-language.com/cpp-iop.html

Здравствуйте, Костя Ещенко, Вы писали:

КЕ>здесь оно выглядит примерно так как он сказал.

Угу, только

  BOOST_INTERFACE_BEGIN(IShape)
    BOOST_INTERFACE_CONST_FUNCTION0(GetX, int)
    BOOST_INTERFACE_CONST_FUNCTION0(GetY, int)
    BOOST_INTERFACE_CONST_FUNCTION0(GetArea, double)
    BOOST_INTERFACE_FUNCTION2(SetXY, void, (int, x), (int, y))
    BOOST_INTERFACE_FUNCTION2(OffSetXY, void, (int, x), (int, y))
    BOOST_INTERFACE_CONST_FUNCTION0(GetName, const char*)
  BOOST_INTERFACE_END(IShape)

не радует сильно.

Хотя если подходить с позиций "шашечки или ехать" то наверное пойдет.
Чего-то правда компайлер уходит в кому на трех таких объявлениях... heavy use of templates наверное

И для тех кто не дошел до этой ссылки
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1510.pdf

Это видение Страуструпа на проблему дискриминации параметров templates.
"heron" interfaces позволяют элегантно решить и эту проблему.

VladD2,

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

Это не так. Для интерфейсов можно сохранить "полный" полиморфизм времени исполнения. В самом деле: зачем пытаться полиморфно работать во время исполнения с конкретными классами? Там где нужен полиморфизм времени исполнения, "ходят" интерфейсы

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

Posted via RSDN NNTP Server 1.9

От:	VladD2	www.nemerle.org
Дата:	12.01.05 01:20
Оценка:

От:	VladD2	www.nemerle.org
Дата:	12.01.05 01:20
Оценка:

От:	VladD2	www.nemerle.org
Дата:	12.01.05 01:20
Оценка:

От:	VladD2	www.nemerle.org
Дата:	12.01.05 01:20
Оценка:

	От:	Павел Кузнецов
	Дата:	12.01.05 01:25
	Оценка:

От:	McSeem2	http://www.antigrain.com
Дата:	12.01.05 01:40
Оценка:

От:	c-smile	http://terrainformatica.com
Дата:	12.01.05 05:33
Оценка:

	От:	Костя Ещенко
	Дата:	12.01.05 05:43
	Оценка:	26 (2)