Здравствуйте, kuj, Вы писали:
M>>То есть, какой смысл писать: M>>
M>>MyInterface : Interface(IUnknown)
M>>
M>>если класс, реализующий MyInterface может спокойно похерить реализацию методов из IUnknown?
kuj>Он не может ее похерить. Никак. MyInterface наследует методы IUnknown. Единственное различие, что в Delphi QueryInterface возвращает только интерфейс, который явно записан в таблицу COM (или как оно там в Делфи реализовано), а кривость дельфового RTTI не дает получить информацию про предков интерфейса...
RTTI как раз таки позволяет (и много чего еще позволяет)
Здравствуйте, hattab, Вы писали:
M>>О. Кстати. Последняя фраза очень четко показывает кривизну такой реализации. Почему класс обязан реализовывать только методы непосредственного предка, а не всех предков по цепочке? Куда подевались методы всех предков? Если мы расширяем базовый интерфейс, разве это не значит, что методы предков никуда не подевались?
H>Мамут, ну сколько можно повторять: понятие наследования интерфейсов не соотносится с понятием наследования классов. Наследование интерфейсов есть суть расширение декларации.
Это только в недоязыках типа Delphi так. В нормальных языках есть полноценная иерархия интерфейсов.
Здравствуйте, hattab, Вы писали:
M>>>То есть, какой смысл писать: M>>>
M>>>MyInterface : Interface(IUnknown)
M>>>
M>>>если класс, реализующий MyInterface может спокойно похерить реализацию методов из IUnknown?
kuj>>Он не может ее похерить. Никак. MyInterface наследует методы IUnknown. Единственное различие, что в Delphi QueryInterface возвращает только интерфейс, который явно записан в таблицу COM (или как оно там в Делфи реализовано), а кривость дельфового RTTI не дает получить информацию про предков интерфейса...
H>RTTI как раз таки позволяет (и много чего еще позволяет)
Что в таком случае мешает неявно добавить всех предков в таблицу COM (или что там в Delphi в этой роли)?
Bigger пишет: > Здравствуйте, OCTAGRAM, Вы писали: > > OCT>Bigger пишет: >> > Вы что курите, хотя больше похоже на тяжелые синтетические наркотики. > OCT>перечитай ещё раз > > Тут сколько не читай, ничего не понятно.
>> > А зачем в одну кучу варианты использования, ООП и СОМ. >> > Первое относится варианты использования системы, т.е. это проектирование >> > системы, на этом этапе наплевать какую парадигму программирования >> > использовать > OCT>в роли системы реализация COM > > Так чтоже сказать то хотел, медленно и по русски
В роли юзера — сам программист, использующий COM. Наследуя, агрегируя,
описывая интерфейсы, и т. д., программист задействует варианты
использования (use cases) COM.
> VB6 неполноценный ООП, а ком на нем писать так что в путь
???
M>>О. Кстати. Последняя фраза очень четко показывает кривизну такой реализации. Почему класс обязан реализовывать только методы непосредственного предка, а не всех предков по цепочке? Куда подевались методы всех предков? Если мы расширяем базовый интерфейс, разве это не значит, что методы предков никуда не подевались?
H>Мамут, ну сколько можно повторять: понятие наследования интерфейсов не соотносится с понятием наследования классов. Наследование интерфейсов есть суть расширение декларации.
Хорошо. Мы расширили декларацию:
MyInterface : Interface(IUnknown)
Почему, согласно твоим словам, я обязан писать:
MyClass : Class(MyInterface, IUnknown)
а не
MyClass : Class(MyInterface)
для реализации IUnknown, если MyInterface всего лишь расширяет, а не подменяет IUnknown?
M>>То есть, какой смысл писать: M>>
M>>MyInterface : Interface(IUnknown)
M>>
M>>если класс, реализующий MyInterface может спокойно похерить реализацию методов из IUnknown?
H>Ничего он не может похерить.
То есть AddRef, Release и QueryInterface в нем все равно будут присутствовать? Тогда любой класс, преализующий любой интерфейс будет COM-объектом, потому что в нем есть три необходимых и достаточных для COM метода — AddRef, Release и QueryInterface
hattab пишет: > kuj>Только без generic`ов ОЙ как плохо. > > Не сильно, если честно Для Delphi 2006 есть неофициальный тул (по сути > препроцессор) который реализует много чего: и дженерики, и case по > строкам, и exit с возвратом результата. В общем кому нужно -- тот найдет.
Когда–то я просто горел идеей препроцессора для Delphi. Решил
посмотреть, что есть. Так, для протокола. Свято место пусто не бывает,
их оказалось целых два. Есть DEEX,
есть DLangExtensions.
Правда проблемы мои были вовсе не те, я хотел специальный синтаксис для
графов, ориентированных и не–, для сбалансированных деревьев и т. д.,
чтоб можно было грамматику менять, так что эти идеи скорее в Seed7.
Впрочем, ни с чем из этого не имел дела и не буду, скорее всего.
Здравствуйте, kuj, Вы писали:
kuj>Или ты пытаешься сказать своим "слово Рихтер", что деструктор в управляемой среде и деструктор в native различаются? Ну так ясное дело различаются. Тем, что в управляемой среде момент вызова деструктора и порядок вызова деструкторов связных объектов недетерминированные.
Здравствуйте, Mr.Cat, Вы писали:
MC>Попробую ответить. MC>.NET развивался как платформа, изначально поддерживающая 3 языка: MC++, C# и VB.NET. Все эти языки изначально не имели funarg problem, можно даже сказать, что на дизайн этих языков стек оказал определенное влияние. Поэтому и в реализации FW был использован стек и стекоориентированный IL. Сейчас смысла что-либо переделывать никакого нет.
Лично я не думаю, что и в будущем появится смысл что-либо переделывать.
Стековая ориентированность IL позволяет во-первых проводить дешевую верификацию кода, а во-вторых генерировать достаточно эффективный целевой код на современных архитектурах.
MC>Функциональные языки не являются основным направлением развития платформы: F# — пока только эксперементальная игрушка, Nemerle — пожалуй, еще не так широко известен и используется, чтобы стать мейнстримом в .NET. Мейнстрим в .NET — это императивные языки. Функциональные возможности, добавленные в C# не делают его функциональным языком, о том, что функция является first-class object говорить нельзя. Поэтому реализация сохранения контекста вызова в виде небольшого "хака" стека — вполне уместна. Т.е. к императивной основе .NET, полагающейся на стек "сбоку" приделали функциональные возможности и реализовали их в рамках имеющихся средств вот и все. Когда функциональность войдет в мейнстрим — вот тогда и полюбуемся на всякие functional language runtime и иже с ними.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: наши менеджеры памяти самые менеджеристые менеджеры п
Здравствуйте, OCTAGRAM, Вы писали: OCT>Я помню, один раз хорошо сэкономил своей команде время на кодинг, OCT>дописав type String = String[255] в начале, без этого не проходило по OCT>времени. А время в разы отличается, как ни крути.
Насколько я помню, был такой ключик компилятора, который дефайнил String как ShortString вместо AnsiString.
Именно с ним были скомпилированы все модули VCL, благодаря чему у компонентов строковые свойства были ShortString.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, kuj, Вы писали:
M>>>>То есть, какой смысл писать: M>>>>
M>>>>MyInterface : Interface(IUnknown)
M>>>>
M>>>>если класс, реализующий MyInterface может спокойно похерить реализацию методов из IUnknown?
kuj>>>Он не может ее похерить. Никак. MyInterface наследует методы IUnknown. Единственное различие, что в Delphi QueryInterface возвращает только интерфейс, который явно записан в таблицу COM (или как оно там в Делфи реализовано), а кривость дельфового RTTI не дает получить информацию про предков интерфейса...
H>>RTTI как раз таки позволяет (и много чего еще позволяет)
kuj>Что в таком случае мешает неявно добавить всех предков в таблицу COM (или что там в Delphi в этой роли)?
Мешает неявность. Язык требует явного указания реализуемых интерфейсов. Кстати, этот вопрос (иерархию) вполне можно разруливать в момент компиляции и без всякой RTTI.
Здравствуйте, Mamut, Вы писали:
H>>Мамут, ну сколько можно повторять: понятие наследования интерфейсов не соотносится с понятием наследования классов. Наследование интерфейсов есть суть расширение декларации.
M>Хорошо. Мы расширили декларацию: M>
M>MyInterface : Interface(IUnknown)
M>
M>Почему, согласно твоим словам, я обязан писать: M>
M>MyClass : Class(MyInterface, IUnknown)
M>
M>а не M>
M>MyClass : Class(MyInterface)
M>
M>для реализации IUnknown, если MyInterface всего лишь расширяет, а не подменяет IUnknown?
MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология.
M>>>То есть, какой смысл писать: M>>>
M>>>MyInterface : Interface(IUnknown)
M>>>
M>>>если класс, реализующий MyInterface может спокойно похерить реализацию методов из IUnknown?
H>>Ничего он не может похерить.
M>То есть AddRef, Release и QueryInterface в нем все равно будут присутствовать? Тогда любой класс, преализующий любой интерфейс будет COM-объектом, потому что в нем есть три необходимых и достаточных для COM метода — AddRef, Release и QueryInterface
Все верно. С чем ты споришь? Класс будет COM-объектом (если таки продекларирует реализацию IUnknown), а MyInterface не будет COM-интерфейсом. Я это уже несколько раз написал.
Здравствуйте, OCTAGRAM, Вы писали:
>> Не сильно, если честно Для Delphi 2006 есть неофициальный тул (по сути >> препроцессор) который реализует много чего: и дженерики, и case по >> строкам, и exit с возвратом результата. В общем кому нужно -- тот найдет. OCT>Когда–то я просто горел идеей препроцессора для Delphi. Решил OCT>посмотреть, что есть. Так, для протокола. Свято место пусто не бывает, OCT>их оказалось целых два. Есть DEEX, OCT>есть DLangExtensions.
Я именно DLangExtensions и имел ввиду
OCT>Правда проблемы мои были вовсе не те, я хотел специальный синтаксис для OCT>графов, ориентированных и не–, для сбалансированных деревьев и т. д., OCT>чтоб можно было грамматику менять, так что эти идеи скорее в Seed7.
OCT>Впрочем, ни с чем из этого не имел дела и не буду, скорее всего.
Аналогично. Я посмотрел, вроде все приятно, но терять совместимость очень не хочется, да и не все желаемые языковые фичи он реализует. Есть надежда, что после покупки CodeGear компанией Embarcadero, развитие языка только продолжится. Кстати, в своем обращении к пользователям, CodeGear сообщает о намерениях вести разработки для гетерогенных платформ (пойдем на Linux, MacOS?)
Re[9]: наши менеджеры памяти самые менеджеристые менеджеры п
Здравствуйте, Sinclair, Вы писали:
OCT>>Я помню, один раз хорошо сэкономил своей команде время на кодинг, OCT>>дописав type String = String[255] в начале, без этого не проходило по OCT>>времени. А время в разы отличается, как ни крути. S>Насколько я помню, был такой ключик компилятора, который дефайнил String как ShortString вместо AnsiString. S>Именно с ним были скомпилированы все модули VCL, благодаря чему у компонентов строковые свойства были ShortString.
Здравствуйте, hattab, Вы писали:
H>MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология.
Эта идеология расходится с ООП. При том, что COM сам по себе никак с ООП не конфликтует.
Это еще раз доказывает что делфи — плохой язык.
Re[10]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали: H>Все с точностью до наоборот
Ты хочешь сказать, что стандартные компоненты VCL скомпилированы с длинными строками в свойствах? Я, правда, не смотрел на Delphi после 7.0, но раньше были именно ShortString. Для совместимости с Delphi 1.0, афаир.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, hattab, Вы писали: H>>Все с точностью до наоборот S>Ты хочешь сказать, что стандартные компоненты VCL скомпилированы с длинными строками в свойствах?
Именно так. В самом сердце VCL (Controls.pas) явно указывается использование AnsiStirng (LongStrings) {$H+}.
S>Я, правда, не смотрел на Delphi после 7.0, но раньше были именно ShortString. Для совместимости с Delphi 1.0, афаир.
Во всех 32-битных версиях AnsiStrings используется по умолчанию.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Mamut, Вы писали:
H>>>Мамут, ну сколько можно повторять: понятие наследования интерфейсов не соотносится с понятием наследования классов. Наследование интерфейсов есть суть расширение декларации.
M>>Хорошо. Мы расширили декларацию: M>>
M>>MyInterface : Interface(IUnknown)
M>>
M>>Почему, согласно твоим словам, я обязан писать: M>>
M>>MyClass : Class(MyInterface, IUnknown)
M>>
M>>а не M>>
M>>MyClass : Class(MyInterface)
M>>
M>>для реализации IUnknown, если MyInterface всего лишь расширяет, а не подменяет IUnknown?
H>MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология.
Обьясни, что значит расширяется.
РАСШИРЯТЬ несов. перех.
1. Делать большим по площади.
2. Увеличивать в количестве, в объеме. 3. перен. Делать более обширным, распространять круг действия чего-л.
В любом нормальном понимании (даже не ЯП — а просто понимании) расширение это:
— мы сохраняем все свойства предыдущей сущности
— мы добавляем к предыдущей сущности новые свойства
И ООП здесь не причем.
M>>>>То есть, какой смысл писать: M>>>>
M>>>>MyInterface : Interface(IUnknown)
M>>>>
M>>>>если класс, реализующий MyInterface может спокойно похерить реализацию методов из IUnknown?
H>>>Ничего он не может похерить.
M>>То есть AddRef, Release и QueryInterface в нем все равно будут присутствовать? Тогда любой класс, преализующий любой интерфейс будет COM-объектом, потому что в нем есть три необходимых и достаточных для COM метода — AddRef, Release и QueryInterface
H>Все верно. С чем ты споришь? Класс будет COM-объектом (если таки продекларирует реализацию IUnknown), а MyInterface не будет COM-интерфейсом. Я это уже несколько раз написал.
Так как объект, реализующий MyInterface все равно обязан реализовать COM-методы AddRef, Release и QueryInterface, то MyInterface все равно является COM-интерфейсом, в котором есть три COM-совместимых метода
Здравствуйте, gandjustas, Вы писали:
H>>MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология. G>Эта идеология расходится с ООП. При том, что COM сам по себе никак с ООП не конфликтует. G>Это еще раз доказывает что делфи — плохой язык.
Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.
Здравствуйте, hattab, Вы писали:
H>Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.
Само понятие расширения однозначно соответствует наследованию в ООП. Во многих языках наследование обозначается ключевым словом extends — "расширяет".
Только в делфи как-то неправильно сделано.
Интерфейсы кстати имеют немалое значение в ООП.
