Re[5]: Закон один для всех - Компьютерные священные войны

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

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

kuj>>>>>Что в таком случае мешает неявно добавить всех предков в таблицу COM (или что там в Delphi в этой роли)?

H>>>>Мешает неявность. Язык требует явного указания реализуемых интерфейсов. Кстати, этот вопрос (иерархию) вполне можно разруливать в момент компиляции и без всякой RTTI.

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

M>>Там все гораздо хуже:
M>>

M>>MyInterface : Interface(IUnknown)

M>>MyClass : Class(MyInterface)

M>>MyClass2 : Class(MyInterface, IUnknown)
M>>

M>>В обоих классах мы обязаны реализовать методы _AddRef, _Release и QueryInterface, потому что так требует их наличие в IUnknown, но MyClass мы не сможем привести к IUnknown. Несмотря на то, что он является наследником IUnknown

H>Мамут, класс не может являться наследником интерфейса.

M>>И эта кривизна называется "идеологией"

H>Как ты можешь рассуждать об идеологии, в то время как, позволяешь себе подобные высказывания (выделено)

Блин. Еще раз. В MyClass мы обязаны реализовывать методы из IUnknown? Да. Является ли он тогда совместимым с IUnknown? Да. Почему я не могу привести его к IUnknown?

... << RSDN@Home 1.2.0 alpha 4 rev. 1084>>

H>>>Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.

M>>Кто это такое сказал?
M>>Интерфейс (объектно-ориентированное программирование)

H>Мамут, ты сам подумай

Ты становишься похожим на kuj'а.

... << RSDN@Home 1.2.0 alpha 4 rev. 1084>>

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

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

H>>>MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология.

M>>Обьясни, что значит расширяется.

M>>

M>>РАСШИРЯТЬ несов. перех.
M>>1. Делать большим по площади.
M>>2. Увеличивать в количестве, в объеме.
M>>3. перен. Делать более обширным, распространять круг действия чего-л.

M>>В любом нормальном понимании (даже не ЯП — а просто понимании) расширение это:
M>>- мы сохраняем все свойства предыдущей сущности
M>>- мы добавляем к предыдущей сущности новые свойства

M>>И ООП здесь не причем.

H>Правильно, ООП тут ни при чем.

Дай свое оределение понятия расширяет

Вот, что я вижу:

MyInterface : Interface(IUnknown)

MyClass : Class(MyInterface)

MyClass обязан реализовывать методы из IUnknown. Потому что MyInterface не подменяет IUnknown, а расширяет. При этом он остается IUnknown. Почему? Потому что любой класс, реализующий MyInterface, обязан реализовать IUnknown.

Далее:

MyInterface : Interface(IUnknown)

MyInterface2 : Interface(MyInterface)

MyClass : Class(MyInterface)

MyClass обязан реализовать и IUnknown и MyInterface2. Потому что MyInterface2 остается как MyInterface, так и MyInterface. Почему? Потому что любой класс, реализующий MyInterface2 обязан реализовать все методы из всех интерфейсов. Это в чистом виде наследование от абстрактных классов.

Но при этом, несмотря на то, что мы уже реаизуем все методы всех интерфейсов по цепочке, мы должны все равно явно указывать компилятору, что мы реализуем эти интерфейсы в том или ином классе. Это ли не верх идиотизма:

MyInterface : Interface(IUnknown)
   someMethod()
end


MyClass : Class(MyInterface)
   //Минимальная реализация
   
   // Обязательная реализация IUnknown
   _AddRef
   _Release
   QueryInterface
   
   // Оязательная реализация MyInterface
   someMethod
end

Я уже реализовал IUnknown. Зачем мне его дополнительно указывать в декарации класса? Если я не могу класс привести к IUnknown, то зачем мне реализовывать методы из IUnknown? Чтобы просто так, тонны дополнительного кода писать?

... << RSDN@Home 1.2.0 alpha 4 rev. 1084>>

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

AJD>>Думаю, с custom маршалером можно будет передать без проблем.

H>Да. Только после этого называть такой интерфейс COM-совместимым, это все равно, что назвать танк летающим только потому, что он в транспортном самолете находится.

Он будет COM-совместимым

. Ты путаешь бинарную COM совместимость с OLE Automation. Да, стандартный OLE automation маршалер работать не будет, ну и что с того?

hattab пишет:
> Это давно не проблема... У джедаев давно есть полный комплект (JWA),
> есть конверторы C2Pas.
Из автоматических генераторов привязок более–менее продвинутый
cableswig. Но вот хотелось бы пусть не полностью автоматический, но с
возможностью специализации под каждую библиотеку. Потому что в пределах
одной библиотеки можно найти множество разных похожих приёмов. И вообще,
эти штуки, пусть не приёмы, а, назовём их, концепты нужно замаппить с
одного языка на другой, и тогда это будет удобная в использовании
привязка, а не просто калька с заголовочных файлов. Мне больше всего
нравится идея, когда есть тонкая привязка и толстая поверх тонкой. Вот,
например, какие в Win32 есть приёмы–концепты? Есть HRESULT. Его можно
было бы завернуть (для каждого вызова) в проверку на результат. Потому
что если проверять результат в Delphi, то это doesn't feel like Delphi,
а если вручную дописывать Succeded(вроде?), то это недостаточно толстые
привязки. А есть ещё особенность WinAPI, когда дополнительный параметр у
Callback пробрасывается через lParam. В других библиотеках параметр
Callback, скорее всего, будет void*. И вот как универсальный биндинг
генератор с этим универсально справится? Универсально можно только
оставить всё как есть, чтобы в привязках были всё те же lParam и void*.
Но это будет тонкая привязка. Толстая привязка давала бы использовать в
качестве Callback методы объектов в Delphi и нисходящие замыкания в Аде.

Я это к тому, что специализируемый генератор привязок может решить
проблему поддержки толстых привязок up to date. Чтобы сделать такой
генератор, нужно обратиться к какому–то динамическому языку. Можно,
конечно, создать с нуля механизм, достаточный для частичного решения
задачи. Вот только это всё равно получается мини–язык. Немало
специализированных мини–языков выросло в нечто большее. И все
несовместимы друг с другом. PHP начинался как несложный механизм HTML
шаблонов. XSLT изначально конвертировал XML в XML. А сейчас уже EXSLT и
FXSLT делают XSLT вполне себе высокоуровневым языком. Ну и GNU m4,
изначально препроцессор, на нём тоже можно писать. Целью родить новый
язык я не задавался, поэтому нужно прибиться к какому–то уже
существующему. Мне Пролог кажется более подходящим.

Хорошие толстые привязки нужны и для Delphi, и для Ada, и для .NET (
http://www.pinvoke.net/ ), и для D. Проблема общая. Пока что все делают
каждый отдельно, и справляются не очень хорошо. Это называется A*B.
Хотелось бы свести A*B к A+B, а, чтобы это произошло, нужно начать
описанный проект.

P. S. оффтопик, однако

--
ISO/IEC 8652:1995/Amd 1:2007

Posted via RSDN NNTP Server 2.1 beta

Sinclair пишет:
> Здравствуйте, OCTAGRAM, Вы писали:
> OCT>Я помню, один раз хорошо сэкономил своей команде время на кодинг,
> OCT>дописав type String = String[255] в начале, без этого не проходило по
> OCT>времени. А время в разы отличается, как ни крути.
> Насколько я помню, был такой ключик компилятора
Ключики компилятора на сервере олимпиад мы менять, конечно, не могли,
поэтому так.

--
ISO/IEC 8652:1995/Amd 1:2007

Posted via RSDN NNTP Server 2.1 beta

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

OCT>Ключики компилятора на сервере олимпиад мы менять, конечно, не могли,
OCT>поэтому так.

Мы делали так: настраивали компилятор через настройки среды.
Потом — Ctrl-O дважды. Эта комбинация клавиш вставляет все настройки компилятора в виде директив в начало исходника.

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

H>>>>Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.
G>>>Само понятие расширения однозначно соответствует наследованию в ООП. Во многих языках наследование обозначается ключевым словом extends — "расширяет".
G>>>Только в делфи как-то неправильно сделано.

H>>Все правильно сделано. Ты просто понять не можешь.
G>Это ты понять не можешь в силу ограниченности кругозора.

Свои домыслы оставь при себе.

G>>>Интерфейсы кстати имеют немалое значение в ООП.
H>>Конечно имеют, кто же спорит.
G>Ты споришь

Это ты сон такой видел, да?

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

H>>>>Во всех 32-битных версиях AnsiStrings используется по умолчанию.

M>>>Они уже научились Юникод содержать и выводить на экран?

H>>Юникод присутствует очень давно. В VCL поддержки юникода нет.

M>Все. На этом на Дельфи можно ставить крест. Если они за нцать лет так и не удосужились в Юникодном мире в свои собственные стандартные компоненты не вставить Юникод

H>> Есть сторонние компоненты, тот же TNT, с поддержкой юникода. Юникод в VCL будет в Тибуроне (Delphi 2008).

M>Внимательно смотри отличие:
M>Java — поддержка Юникода нативно
M>.NET — поддержка Юникода нативно
M>Qt — поддержка Юникода нативно
M>Delphi- а вот есть сторонние компоненты...

Главное, решение-то есть. Да и язык сей факт ни как не характеризует.

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

H>>>> ...CodeGear сообщает о намерениях вести разработки для гетерогенных платформ (пойдем на Linux, MacOS?)

S>>>они бы хидеры из Windows SDK хоть перевели на Delphi...

H>>Это давно не проблема... У джедаев давно есть полный комплект (JWA), есть конверторы C2Pas.

S>простой пример — DirectShow. Видел 3 варианта, во всех куча багов и нет Вистовских фич вроде EVR в нормальном виде.

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

S>начнешь плотно работать — видно сколь криво это сделано. а чтото более бажное и громоздкое чем JVCL вообще сложно представить.

JWA <> JVCL.

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

H>>>>>Мешает неявность. Язык требует явного указания реализуемых интерфейсов. Кстати, этот вопрос (иерархию) вполне можно разруливать в момент компиляции и без всякой RTTI.

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

M>>>Там все гораздо хуже:
M>>>

M>>>MyInterface : Interface(IUnknown)

M>>>MyClass : Class(MyInterface)

M>>>MyClass2 : Class(MyInterface, IUnknown)
M>>>

M>>>В обоих классах мы обязаны реализовать методы _AddRef, _Release и QueryInterface, потому что так требует их наличие в IUnknown, но MyClass мы не сможем привести к IUnknown. Несмотря на то, что он является наследником IUnknown

H>>Мамут, класс не может являться наследником интерфейса.

M>>>И эта кривизна называется "идеологией"

H>>Как ты можешь рассуждать об идеологии, в то время как, позволяешь себе подобные высказывания (выделено)

M>Блин. Еще раз. В MyClass мы обязаны реализовывать методы из IUnknown? Да. Является ли он тогда совместимым с IUnknown? Да. Почему я не могу привести его к IUnknown?

Нет, он не является совместимым с IUnknown т.к. IUnknown не продекларирован в списке реализуемых интерфейсов и реализуешь ты методы не IUnknown, а MyInterface. Я это повторил уже раз десять.

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

H>>>>Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.

M>>>Кто это такое сказал?
M>>>Интерфейс (объектно-ориентированное программирование)

H>>Мамут, ты сам подумай

M>Ты становишься похожим на kuj'а.

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

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

G>>>>Интерфейсы кстати имеют немалое значение в ООП.
H>>>Конечно имеют, кто же спорит.
G>>Ты споришь

H>Это ты сон такой видел, да?

Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.

Не ты писал?

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

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

M>>Внимательно смотри отличие:
M>>Java — поддержка Юникода нативно
M>>.NET — поддержка Юникода нативно
M>>Qt — поддержка Юникода нативно
M>>Delphi- а вот есть сторонние компоненты...

H>Главное, решение-то есть. Да и язык сей факт ни как не характеризует.
Зато платформу очень даже характеризует.

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

H>>>>MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология.

M>>>Обьясни, что значит расширяется.

M>>>

M>>>РАСШИРЯТЬ несов. перех.
M>>>1. Делать большим по площади.
M>>>2. Увеличивать в количестве, в объеме.
M>>>3. перен. Делать более обширным, распространять круг действия чего-л.

M>>>В любом нормальном понимании (даже не ЯП — а просто понимании) расширение это:
M>>>- мы сохраняем все свойства предыдущей сущности
M>>>- мы добавляем к предыдущей сущности новые свойства

M>>>И ООП здесь не причем.

H>>Правильно, ООП тут ни при чем.

M>Дай свое оределение понятия расширяет

Я же специально для тебя выделил. Читай внимательно.

M>Вот, что я вижу:

M>

M>MyInterface : Interface(IUnknown)

M>MyClass : Class(MyInterface)
M>

M>MyClass обязан реализовывать методы из IUnknown. Потому что MyInterface не подменяет IUnknown, а расширяет. При этом он остается IUnknown. Почему? Потому что любой класс, реализующий MyInterface, обязан реализовать IUnknown.

MyInterface расширяется декларацией IUnknown. MyInterface можно приводить к IUnknown. Это понятно?

M>Далее:
M>

M>MyInterface : Interface(IUnknown)

M>MyInterface2 : Interface(MyInterface)

M>MyClass : Class(MyInterface)
M>

M>MyClass обязан реализовать и IUnknown и MyInterface2. Потому что MyInterface2 остается как MyInterface, так и MyInterface. Почему? Потому что любой класс, реализующий MyInterface2 обязан реализовать все методы из всех интерфейсов. Это в чистом виде наследование от абстрактных классов.

Перечитай свой абзац -- это абзац

MyClass обязан реализовать MyInterface, не IUnknown. В Delphi интерфейсы полностью соответствуют идеологии и являются абсолютными абстракциями, перестань натягивать терминологию C++ с абстрактными классами.

M>Но при этом, несмотря на то, что мы уже реаизуем все методы всех интерфейсов по цепочке, мы должны все равно явно указывать компилятору, что мы реализуем эти интерфейсы в том или ином классе. Это ли не верх идиотизма:

Еще раз. Расширение ни есть наследование. Постарайся посмотреть на это под другим углом.

M>

M>MyInterface : Interface(IUnknown)
M>   someMethod()
M>end


M>MyClass : Class(MyInterface)
M>   //Минимальная реализация
   
M>   // Обязательная реализация IUnknown
M>   _AddRef
M>   _Release
M>   QueryInterface
   
M>   // Оязательная реализация MyInterface
M>   someMethod
M>end
M>

M>Я уже реализовал IUnknown. Зачем мне его дополнительно указывать в декарации класса? Если я не могу класс привести к IUnknown, то зачем мне реализовывать методы из IUnknown? Чтобы просто так, тонны дополнительного кода писать?

Жаль, что ты так и не понял... Реализуешь ты тут только MyInterface полученый путем расширения декларации от IUnknown.

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

AJD>>>Думаю, с custom маршалером можно будет передать без проблем.

H>>Да. Только после этого называть такой интерфейс COM-совместимым, это все равно, что назвать танк летающим только потому, что он в транспортном самолете находится.

AJD>Он будет COM-совместимым

. Ты путаешь бинарную COM совместимость с OLE Automation. Да, стандартный OLE automation маршалер работать не будет, ну и что с того?

А про бинарную совместимость ни кто и не спорил

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

H>Нет, он не является совместимым с IUnknown т.к. IUnknown не продекларирован в списке реализуемых интерфейсов и реализуешь ты методы не IUnknown, а MyInterface. Я это повторил уже раз десять.

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

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

G>>>>>Интерфейсы кстати имеют немалое значение в ООП.
H>>>>Конечно имеют, кто же спорит.
G>>>Ты споришь

H>>Это ты сон такой видел, да?

G>

G>Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.

G>Не ты писал?

И еще раз напишу, чтоб ты понял: Наследование, инкапсуляция и полиморфизм, вот фундамент ООП. Интерфейсы, да приятная штука снимающая зависимости кода, не более того.

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

H>И еще раз напишу, чтоб ты понял: Наследование, инкапсуляция и полиморфизм, вот фундамент ООП. Интерфейсы, да приятная штука снимающая зависимости кода, не более того.
Интерфейсы не имеют отношения к наследованию и полиморфизму?

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

AJD>>>>Думаю, с custom маршалером можно будет передать без проблем.

AJD>>Он будет COM-совместимым

. Ты путаешь бинарную COM совместимость с OLE Automation. Да, стандартный OLE automation маршалер работать не будет, ну и что с того?

H>А про бинарную совместимость ни кто и не спорил

Да. Только после этого называть такой интерфейс COM-совместимым, это все равно, что назвать танк летающим только потому, что он в транспортном самолете находится. (c)hattab

А эту фразу как понимать?

От:	Mamut	http://dmitriid.com
Дата:	13.05.08 06:09
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	13.05.08 06:09
Оценка:	+2

От:	Mamut	http://dmitriid.com
Дата:	13.05.08 06:24
Оценка:

	От:	AndrewJD
	Дата:	13.05.08 09:12
	Оценка:	+1

От:	OCTAGRAM	http://octagram.name/
Дата:	13.05.08 18:31
Оценка:	2 (2)

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	13.05.08 20:27
Оценка: