c-smile,
> ПК> Единственный тонкий момент, пока для меня в Хероне не очевидный, заключается в управлении временем жизни объектов, к которым привязаны интерфейсы. Нужно смотреть
>
> Extending the Lifetime of temporaries
> Using an interface variable as an lvalue extends the lifetime of that temporary in the same way that assigning a temporary to a reference does.
С временем жизни локальных объектов все более-менее понятно. А вот, что делать, когда время жизни интерфейса превышает время жизни функции? Например, возврат интерфейса из функции...
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
The most prominent difference is that they do not require declarations within a class of intention to implement an interface
Не думаю что это преимущество. Впрочем я про это уже писал.
ПК>
any class can be used polymorphically
В дотнете тоже.
ПК>
Function pointers can be effectively implemented as intefaces with only one function. This helps simplify the language significantly when compared to C++ for instance.
ПК>Т.е. ни указателей на функции, ни делегатов не нужно. В отличие, скажем, от inner классов Java (или как там они называются?), интерфейсы Heron в этом отношении предоставляет полноценную замену этим сущностям.
Фиговую они замену предлагают. Как только понадобится подписаться на несколько одинаковых событий настанет редкая задница, поскольку при отсутствии явного указания интерфейсов и явная их реализация невозможна. Делегаты на порядок гибче и удобнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Не единственный. А если говорить не о runtime полиморфизме вообще,
Ну, продемонстрируй что я получу от них чего я не могу получить на сегодня в Шарпе (кроме потенциального ускорения)?
ПК>а конкретно о виртуальных функциях, то вот преимущества интерфейсов Heron (или соответствующие недостатки виртуальных функций), как их видит автор, за вычетом соображений о быстродействии:
ПК>http://www.heron-language.com/interfaces.html
Полностью согласен с АВК. Автору бы прежде чем переизобретать велосипен познакомиться бы с тем как все сделано в Шарпе. Может и желаение отпало бы.
В общем, я своего мнения не изменил. Это действительно интересный взгляд. Но он имеет явные недостакти. Возможно подобный механизм мог бы поднять качество С++, но для нового языка он хуже чем интерфейсы + делегаты я-ла Шарп. Ну, а скорость дело наживное.
... << RSDN@Home 1.1.4 beta 3 rev. 273>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Влад, у вас с Andrew какие-то не-лады с определением причинно-следственных связей,
У вас проблемы с пониманием. От вам 30-тое сообщение пытается обяснить, что схема менее гибка, так как или небуедет полноценного рантайм-полиморфизма, или будут дикие накладные расходы в рантайме.
... << RSDN@Home 1.1.4 beta 3 rev. 273>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Это не так. Для интерфейсов можно сохранить "полный" полиморфизм времени исполнения.
Полиморфизм нужен не только для интерфейсов. Модель типа будет не полной если нельзя будет сделать код вроде:
ClassA a = new B();
object o = a;
((Itf)o).Call();
при условии, что а не реализует интерфейс Itf (в терминах Хренорона не содержит нужных функций), а B порожден от A и реализует нужный интерфейс (содержит нужные функции).
А неполная модель уже есть убогость. И вообще с точки зрения программиста, если абстрагироваться от скорости исполнения, нет никакой разницы рантаймный полиморфизм или статический. Важен сам факт. Учитывая это знание о типе полиморфизма есть зло. И от него нужно избавляться. А подход Хренорона как раз приводит нас обратно к таковому знанию.
Итого (повторяюсь в 3-ий раз) — для С++ такой механизм скорее всего был бы благом. Но для нового, безкомпромисного языка он являеться злом.
ПК> В самом деле: зачем пытаться полиморфно работать во время исполнения с конкретными классами?
Вот. Как раз проявление мышления на уровне компилятора. Ты подминил понятие полиморфизм и динамический полиморфизм и ведеш какие-то рассуждения. Реально полиморфизм или есть, или его нет. И лично я, не хочу думать о его природе и скорости. Я хочу иметь компилятор который сам все разрулит и даст мне спокойно писать универсальный и красивый код.
ПК> Там где нужен полиморфизм времени исполнения, "ходят" интерфейсы
Вот и нафиг все это. Пусть лошать... тьфу ты... компилятор и рантайм думают. А я буду думать о решаемой задаче.
ПК>Единственный тонкий момент, пока для меня в Хероне не очевидный, заключается в управлении временем жизни объектов, к которым привязаны интерфейсы. Нужно смотреть
Для тех для кого память больше не ресурс — это не вопрос.
... << RSDN@Home 1.1.4 beta 3 rev. 273>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>С временем жизни локальных объектов все более-менее понятно. А вот, что делать, когда время жизни интерфейса превышает время жизни функции? Например, возврат интерфейса из функции...
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, McSeem2, Вы писали:
MS>>Влад, у вас с Andrew какие-то не-лады с определением причинно-следственных связей,
VD>У вас проблемы с пониманием. От вам 30-тое сообщение пытается обяснить, что схема менее гибка, так как или небуедет полноценного рантайм-полиморфизма, или будут дикие накладные расходы в рантайме.
Это если смотреть на проблему с позиций несимметричного-диметилполиморфизма, а если смотреть на эту проблему незатуманенным фрейморковкой взглядом банальной эрудици то все будет пучком.
Я так думаю.
Достаточно ли энтропии в моем ответе?
Я понимаю что в .NET мышление осуществляется глобальными и крупными категориями вида "рантайм-полиморфизма"... Но мне сирому так и не понятно что конкретно это обозначает. "Это что-то из .NET или мы всегда этим занималтсь?"
Здравствуйте, VladD2, Вы писали:
VD>Ну, продемонстрируй что я получу от них чего я не могу получить на сегодня в Шарпе (кроме потенциального ускорения)?
Знаешь, на практике, необходимость наследования от интерфейса — это такой суксь с точки зрения разруливания взаимных зависимостей в сложных случаях. Не надо только начинать сагу о "грамотном проектировании". В этом смысле свобода выражения мыслей как в шаблонах, но с более строгой верификацией сигнатур методов — это как лучик надежды в кромешной тьме протухшей парадигмы о наследовании.
VD>Полностью согласен с АВК. Автору бы прежде чем переизобретать велосипен познакомиться бы с тем как все сделано в Шарпе. Может и желаение отпало бы.
Он свое желание изолентой примотал. Лично я не хочу, чтобы у меня "отпало желание". Несмотря ни на какие шарпы...
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>Возможно подобный механизм мог бы поднять качество С++, но для нового языка он хуже чем интерфейсы + делегаты я-ла Шарп. Ну, а скорость дело наживное.
Как сказал некий рыцарь Ланцелот из фильма "Убить дракона",
Я начал завидовать рабам. Они все знают заранее. У них тверррдые убеждения. Наверное потому, что у них нет выбора. А рыцарь — он всегда на растутье дорог.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>Полиморфизм нужен не только для интерфейсов. Модель типа будет не полной если нельзя будет сделать код вроде: VD>
VD>ClassA a = new B();
VD>object o = a;
VD>((Itf)o).Call();
VD>
VD>при условии, что а не реализует интерфейс Itf (в терминах Хренорона не содержит нужных функций), а B порожден от A и реализует нужный интерфейс (содержит нужные функции).
Такое преобразование — очень дорогое удовольствие и я бы хотел чтобы система ограждала от подобных решений.
Для таких конструкций есть scripting и VisualBasic c IDispatch.
Твой пример это не полиморфизм (будем считать это определением полиморфизма)
Поли-морфизм это "несколько" и "форма".
Твой cast на object литает объект формы. Вообще.
Т.е. чтобы это работало кто-то должен определить что есть
Здравствуйте, VladD2, Вы писали:
VD>Вот и нафиг все это. Пусть лошать...
Грубая ошибка! В деревне Троицкое Угличского района Ярославской области, где я провел все детство, это слово звучит так: лошоть с ударением на первом слоге и четким 'о' во втором...
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
VladD2,
> ПК> Это не так. Для интерфейсов можно сохранить "полный" полиморфизм времени исполнения.
> Полиморфизм нужен не только для интерфейсов. Модель типа будет не полной если нельзя будет сделать код вроде: >
> ClassA a = new B();
> object o = a;
> ((Itf)o).Call();
>
Выделенная строка — насколько я понимаю идею автора обсуждаемого языка, пример того, что просто-напросто не имеет смысла делать в языке типа Heron. Вместо этого, если нужно работать через "базу", B будет "приводиться" к какому-нибудь интерфейсу или что-то в таком роде.
> И вообще с точки зрения программиста, если абстрагироваться от скорости исполнения, нет никакой разницы рантаймный полиморфизм или статический.
Принципиальная разница есть: чем меньше в программе динамического полиморфизма, тем проще и полнее можно верифицировать ее корректность. В т.ч. для динамического полиморфизма ошибки проявляются во время исполнения.
> ПК> В самом деле: зачем пытаться полиморфно работать во время исполнения с конкретными классами?
> Вот. Как раз проявление мышления на уровне компилятора.
Это уровень концепций. В такой модели наследование классов — наследование реализации, иерархии интерфейсов — динамический полиморфизм. Суть отделение мух от котлет на уровне логики. Упрощение оптимизации — приятный бонус.
> Реально полиморфизм или есть, или его нет. И лично я, не хочу думать о его природе и скорости. Я хочу иметь компилятор который сам все разрулит и даст мне спокойно писать универсальный и красивый код.
Поиски компонента TProgrammer продолжались...
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, c-smile, Вы писали:
CS>Это если смотреть на проблему с позиций несимметричного-диметилполиморфизма, а если смотреть на эту проблему незатуманенным фрейморковкой взглядом банальной эрудици то все будет пучком. CS>Я так думаю.
Я все же предпочту замутненный взгляд, чем ужимки и компромисы. Ну, перспективнее он по-моему. И вообще с теми кто считает, что компромисы это хорошо мне не по пути. Мне нужен идеал, а не чуть лучшее чем совсем плохое.
CS>Достаточно ли энтропии в моем ответе?
Тебе виднее.
CS>Я понимаю что в .NET мышление осуществляется глобальными и крупными категориями вида "рантайм-полиморфизма"...
Да нет. Не понимешь. Дизайнеры дотнета просто вообще хотя исключить эти ненужные понятия. Полиморфизма более чем достаточно. А рантайм или компайлтайм — это пусть у разработчиков компиляторов и оптимизаторов болит.
Это я называю грамотным дизайном с рассчетом на будущее. И такой дизайн мне по душе.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Грубая ошибка! В деревне Троицкое Угличского района Ярославской области, где я провел все детство, это слово звучит так: лошоть с ударением на первом слоге и четким 'о' во втором...
Ну, по кривляйся еще проведешь остаток детства в бане.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Выделенная строка — насколько я понимаю идею автора обсуждаемого языка, пример того, что просто-напросто не имеет смысла делать в языке типа Heron. Вместо этого, если нужно работать через "базу", B будет "приводиться" к какому-нибудь интерфейсу или что-то в таком роде.
Ну, и это явно не гибко.
>> И вообще с точки зрения программиста, если абстрагироваться от скорости исполнения, нет никакой разницы рантаймный полиморфизм или статический.
ПК>Принципиальная разница есть: чем меньше в программе динамического полиморфизма, тем проще и полнее можно верифицировать ее корректность.
Вот такую антиобъектную ересь я от тебя не ждал. Всю жизнь хорошие архитекторы закладывались на абстракцию и считали любые звсисимости не нее вредом. А тут оказывается, что это зло.
ПК> В т.ч. для динамического полиморфизма ошибки проявляются во время исполнения.
Вовсе нет. Все что можно проверить при компиляции можно при ней и проверять. А если уж есть намеренное обращение к вещам которые проверяются только в рантайме, то и нечего тут обсуждать. Главное чтобы такие проверки были.
Еще раз повторю свою мысль. Программист просто не должен оперировать понятимями "динамический полиморфизм" и т.п. Для него есть полиморфизм, а все проблемы пусть решает компилятор. Рантай же был есть и будет. Иначе вообще нет смысла в программх. Можно настроить таблиц решений на все случаи жизни и закрыть на этом тему вычислений.
>> Вот. Как раз проявление мышления на уровне компилятора.
ПК>Это уровень концепций.
Не. На уровне оптимизатора компилятора. Хтя для кого-то это тоже концептуальный уровень.
ПК> В такой модели наследование классов — наследование реализации, иерархии интерфейсов — динамический полиморфизм. Суть отделение мух от котлет на уровне логики.
Боюсь, что идея Хрона — это не более чем попытка выкрутиться из паутины насставленной шаблонами С++. Для этого идея бесспорно хороша. Но она не универсальна и имеет проблемы. Так что я все же предпочел бы решение с явными интерфейсами...
ПК> Упрощение оптимизации — приятный бонус.
...Хотя от приятных бонусов тоже не отказался бы.
>> Реально полиморфизм или есть, или его нет. И лично я, не хочу думать о его природе и скорости. Я хочу иметь компилятор который сам все разрулит и даст мне спокойно писать универсальный и красивый код.
ПК>Поиски компонента TProgrammer продолжались...
Не нужно накливать ярлыки на оппонентов. О панацеях никто не говорит. Я просто анализирую два решения. Главным образом их перспективность.
Мне нравятся концептуально чистые идеи. Чем меньше "если", тем лучше.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ПК>>Принципиальная разница есть: чем меньше в программе динамического полиморфизма, тем проще и полнее можно верифицировать ее корректность.
VD>Вот такую антиобъектную ересь я от тебя не ждал. Всю жизнь хорошие архитекторы закладывались на абстракцию и считали любые звсисимости не нее вредом. А тут оказывается, что это зло.
Просто Павел уже достиг следующей стадии просветления, пока что недоступной тебе Если говорить очень-очень утрированно, то это звучит так:
Первый уровень. "Не понимаю, зачем вообще нужно это наследование".
Второй уровень. "Единственный способ написать правильную программу — это использовать наследование".
Третий уровень. "Концепция наследования — это атрофизм, не имеющий ничего общего с решаемыми задачами, и чем его меньше — тем лучше".
Некоторые люди не могут подняться выше первого уровня. Другие — всю жизнь остаются на втором. Наиболее продвинутые поднимаются до осознания третьего уровня. Ну самые отвязные и безбашенные — с левой резьбой — занимаются изобретением новых концепций, типа херона . А догматики в упор не видят (и не могут видеть) — в чем же тут фишка.
Это просто-напросто вопрос мировоззрения.
Вот хот-дог — это когда плескают в морду коньяком. Фрирайдеры это тоже делают, но они не знают, что когда они плескают в морду коньяком, они становятся хот-догерами. Понимаешь? Вот в чем разница. Во фрирайде можно все. Но есть ограничения. А в хот-доге ограничений просто нет. Потому что по определению их быть не может. Понимаешь?
http://ski-club.org.ru/people/bychkov.shtml
Конечно, мне до такого далеко, но в глубине души я тоже стремлюсь к "хот-догу".
ПК>> В т.ч. для динамического полиморфизма ошибки проявляются во время исполнения.
Именно так оно и есть. Лично для меня нет никакой разницы, падает ли приложение по GPF или по .Net exception.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Первый уровень. "Не понимаю, зачем вообще нужно это наследование". MS>Второй уровень. "Единственный способ написать правильную программу — это использовать наследование". MS>Третий уровень. "Концепция наследования — это атрофизм, не имеющий ничего общего с решаемыми задачами, и чем его меньше — тем лучше".
Четвертый уровень: "А все таки польза от наследования есть"
ПК>>> В т.ч. для динамического полиморфизма ошибки проявляются во время исполнения. MS>Именно так оно и есть. Лично для меня нет никакой разницы, падает ли приложение по GPF или по .Net exception.
А для меня есть. Видимо потому что написание серверов накладывает свой отпечаток на мировоззрение
