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

V>>Слишком громко сказано. Дотнет и Ява вообще возможны только лишь по той причине, что 150 метров на диске и 30-80 метров в памяти — это плевое дело нынче. Да и процы шустрые ноне.

AVK>Ну и какой из этого вывод?

Вывод был в той строке, которую ты опустил.

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

V>>>Слишком громко сказано. Дотнет и Ява вообще возможны только лишь по той причине, что 150 метров на диске и 30-80 метров в памяти — это плевое дело нынче. Да и процы шустрые ноне.

AVK>>Ну и какой из этого вывод?

V>Вывод был в той строке, которую ты опустил.

Не заметил.

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

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

AVK>>>Мудрые мужи стараются не придерживаться замшелых принципов и позволяют от компонентов наследоваться.
V>>С т.з. зрения наследника — это уже не компонент а класс, иначе никак.

AVK>С чего ты взял что не компонент? Вполне компонент.

Вполне не компонент

(и т.д.)



V>>Компонент — это "черный" ящик с парой интерфейсов.

AVK>Так наследник точно так же имеет интерфейс к базовому классу, только он несколько расширен по сравнению с публичным.

Мы имеем protected члены, которые НЕ являются интерфейсом класса для внешнего мира, а служат для использования наследниками. Я понимаю твой ход рассуждений насчет своеобразного интерфейса для наследников, однако мы ПРИНЦИПИАЛЬНО можем иметь доступ не только к методам, инкапсулирующим алгоритмы изменения состояний объекта, но и просто к полям, т.е. "сырым" данным. И в этом смысле нам открывается нечто более, чем самодостаточный интерфейс базового класса. Мы обязаны выступить не как "пользователь" интерфейса класса, но как его разработчик, соблюдая внутреннюю задумку нашего базового типа, ибо элементарно можем ее поломать.


V>>Ты все время говоришь о классах, ИМХО.

AVK>Класс дотнета есть частный случай компонента.

Не всякий класс дотнета является компонентом.

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

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

V>>Более поздние их "велосипеды" не так уж плохи: WTL, GdiPlus,
V>>а по поводу дотнета даже куча ярых приверженцев на RSDN

AVK>К сожалению в случае гуев в дотнете они недалеко ушли. Винформсы по архитектуре это где то середина 90-х. А Avalon еще неизвестно когда будет.

Разве MFC — это только ГУИ?
Разве GuiPlus (активно использующийся дотнетом на вынь) — это Windows.Forms?
Windows.Drawing вполне потянет

А насчет Windows.Forms, дык, я думаю им некогда было изобретать еще один велосипед,
они 1-в-1 взяли интерфейсы и алгоритмы из ActiveX Control Host, на этом у них построено все взаимодействие м/у контролами. Т.е. взяли надежную, испытанную десятилетием технологию

Заодно "попутно" получили совместимость с де-факто существующей тонной ActiveX-компонентов, что на начальных этапах "раскрутки" технологии давало немало дополнительных очков...

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

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

V>>Да, за MFC им надо руки оторвать. Вернее не за MFC (для конца 80-х это было нормально), а за агрессивное его продвижение в начале 90-х.

AJD>Какой-такой конец 80-х? Что-то неприпоминаю MFC под DOS

А вот я припоминаю под Win3.1

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

AVK>>>Ну и какой из этого вывод?

V>>Вывод был в той строке, которую ты опустил.

AVK>Не заметил.

здесь

Автор: vdimas
Дата: 07.11.04

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

V>>>Да, за MFC им надо руки оторвать. Вернее не за MFC (для конца 80-х это было нормально), а за агрессивное его продвижение в начале 90-х.
AJD>>Какой-такой конец 80-х? Что-то неприпоминаю MFC под DOS
V>А вот я припоминаю под Win3.1
Да, MSVC 1.5 и MFC примерно такой же версии.

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

VD>>А Ява думешь что такое? У нее компонентный подход в сердцевине идеологии. Каждый класс — компенент.
ГВ>Угумс, потому и подрались

PS. Вернее, не "потому", а "ради того".

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

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

K>>Скорее всего на шарпе будет только UI. Да и то я не вижу особых преимуществ юзать дотнет в такой системе.

VD>Видимо по этому они не взяли тебя главным архитектором.

Да нет просто перевод акада на дот-нет судя повсему оказался пустым трепом. Можешь глянуть к нему девелоперскую докцументацию. Мелкие макросы в нем можно и на ВБ писать, а для серьезных вещей: ObjectARX — набор плюсовых библиотек.

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

V>Мы имеем protected члены, которые НЕ являются интерфейсом класса для внешнего мира,

Почему?

V>Я понимаю твой ход рассуждений насчет своеобразного интерфейса для наследников, однако мы ПРИНЦИПИАЛЬНО можем иметь доступ не только к методам, инкапсулирующим алгоритмы изменения состояний объекта, но и просто к полям, т.е. "сырым" данным.

Если их объявить доступными наследникам. Но ровно так же мы можем объявить поля и публичными.

V> И в этом смысле нам открывается нечто более, чем самодостаточный интерфейс базового класса. Мы обязаны выступить не как "пользователь" интерфейса класса, но как его разработчик, соблюдая внутреннюю задумку нашего базового типа, ибо элементарно можем ее поломать.

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

AVK>>Класс дотнета есть частный случай компонента.

V>Не всякий класс дотнета является компонентом.

Всякий.

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

AVK>>К сожалению в случае гуев в дотнете они недалеко ушли. Винформсы по архитектуре это где то середина 90-х. А Avalon еще неизвестно когда будет.

V>Разве MFC — это только ГУИ?

Изначально да.

V>Разве GuiPlus (активно использующийся дотнетом на вынь)

GDI+

V> — это Windows.Forms?

Нет. Это даже не дотнет.

V>Windows.Drawing вполне потянет

System.Drawing?

V>А насчет Windows.Forms, дык, я думаю им некогда было изобретать еще один велосипед,

Ну теперь то изобретают.

V>они 1-в-1 взяли интерфейсы и алгоритмы из ActiveX Control Host, на этом у них построено все взаимодействие м/у контролами.

Совсем не похоже. Винформсы это скорее новая реинкарнация VCL.

V>Заодно "попутно" получили совместимость с де-факто существующей тонной ActiveX-компонентов, что на начальных этапах "раскрутки" технологии давало немало дополнительных очков...

Нет там никакой такой совместимости — все взаимодействие через обертки.

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

V>>>Да, за MFC им надо руки оторвать. Вернее не за MFC (для конца 80-х это было нормально), а за агрессивное его продвижение в начале 90-х.

AJD>>Какой-такой конец 80-х? Что-то неприпоминаю MFC под DOS

V>А вот я припоминаю под Win3.1

Может это был где-то 93 год?

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

V>>Запускал дотнет на вынь-СЕ?

AVK>Запускал. Ничего сверхужасного. А учитывая тенденции скоро на КПК будет 1Ггц и 256М памяти, а этого уже достаточно с большим запасом.

Во-первых, не так скоро,
Во-вторых, не на всех.

Для меня ужас в том, что как системный программист, я прекрасно знаю, какие возможности дает 200МГц проц, офигенные, скажем, возможности при правильной их утилизации. То, что показывает этот дотнет на вынь СЕ — это именно сверхужасно.
По крайней мере, было принято решение еще долго не использовать дотнет на всевозможных планшетах, хотя ОЧЕНЬ хотелось, для одной немаленькой системы.

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

AVK>>Запускал. Ничего сверхужасного. А учитывая тенденции скоро на КПК будет 1Ггц и 256М памяти, а этого уже достаточно с большим запасом.

V>Во-первых, не так скоро,

Ну сейчас например новый стандарт >600МГц, 128М памяти. Тоже неплохо.

V>Для меня ужас в том, что как системный программист, я прекрасно знаю, какие возможности дает 200МГц проц,

Какой именно? Если ты о КПКшных, то не все там так просто.

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

V>>Мы имеем protected члены, которые НЕ являются интерфейсом класса для внешнего мира,

AVK>Почему?
?

V>>Я понимаю твой ход рассуждений насчет своеобразного интерфейса для наследников, однако мы ПРИНЦИПИАЛЬНО можем иметь доступ не только к методам, инкапсулирующим алгоритмы изменения состояний объекта, но и просто к полям, т.е. "сырым" данным.

AVK>Если их объявить доступными наследникам. Но ровно так же мы можем объявить поля и публичными.

V>> И в этом смысле нам открывается нечто более, чем самодостаточный интерфейс базового класса. Мы обязаны выступить не как "пользователь" интерфейса класса, но как его разработчик, соблюдая внутреннюю задумку нашего базового типа, ибо элементарно можем ее поломать.

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

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

V>>Не всякий класс дотнета является компонентом.

AVK>Всякий.
Абстракный — не компонент.
Не наследующий IComponent не может визуально обрабатываться студией, т.е. не выполняет задачи компонента: бинарное распространение и автоматизированное использование (ручками я могу равнотрудоемко и сорсы использовать).

Если принять твой взгляд на компонент, то ДДЛ-ка писанная на С++ впридачу с h-файлом тоже вполне компонент.

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

V>>И сейчас можно выбранные дрова слинковать в ядро.

AVK>Раньше по другому было нельзя.

в Линухе нет, в "больших" юнихах — да

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

V>>Разве MFC — это только ГУИ?

AVK>Изначально да.

Тогда весь вынь-апи — изначально только ГУИ

(хотя, где-то так и есть, именно ради ГУЯ вынь и была писана)

V>>Разве GuiPlus (активно использующийся дотнетом на вынь)

AVK>GDI+

тогда уж GdiPlus,
GDI+ — маркетинговое название

V>> — это Windows.Forms?

AVK>Нет. Это даже не дотнет.
ну блин, тогда и Windows.Forms не дотнет, ибо стандартные контролы — это роперы над нативными контролами вынь.

AVK>System.Drawing?
угу, разве это не к ГУИ относится?

V>>А насчет Windows.Forms, дык, я думаю им некогда было изобретать еще один велосипед,

AVK>Ну теперь то изобретают.

V>>они 1-в-1 взяли интерфейсы и алгоритмы из ActiveX Control Host, на этом у них построено все взаимодействие м/у контролами.

AVK>Совсем не похоже. Винформсы это скорее новая реинкарнация VCL.

Я не по духу, а по имплементации:

public class Control : Component, UnsafeNativeMethods.IOleControl, UnsafeNativeMethods.IOleObject, 
UnsafeNativeMethods.IOleInPlaceObject, UnsafeNativeMethods.IOleInPlaceActiveObject, 
UnsafeNativeMethods.IOleWindow, UnsafeNativeMethods.IViewObject, UnsafeNativeMethods.IViewObject2, 
UnsafeNativeMethods.IPersist, UnsafeNativeMethods.IPersistStreamInit, UnsafeNativeMethods.IPersistPropertyBag, 
UnsafeNativeMethods.IPersistStorage, UnsafeNativeMethods.IQuickActivate, ISupportOleDropSource, IDropTarget, 
ISynchronizeInvoke, IEnablable, IWin32Window, IArrangedElement, IBindableComponent, IComponent, IDisposable

это стандартный ActiveX


V>>Заодно "попутно" получили совместимость с де-факто существующей тонной ActiveX-компонентов, что на начальных этапах "раскрутки" технологии давало немало дополнительных очков...

AVK>Нет там никакой такой совместимости — все взаимодействие через обертки.

речь не о декларируемых интерфейсы COM-объекта, а именно про его поднаготную, IOleControl, IOleObject, IViewObject, IOleWindow, и т.д.

С этой штукой Windows.Forms работают так же как и со своими "родными" контролами.

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

V>>>Мы имеем protected члены, которые НЕ являются интерфейсом класса для внешнего мира,

AVK>>Почему?
V>?

Почему protected-члены не являются интерфейсом класса?

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

V>Весьма расплывчато понятие грамотности. Объявлять поля публичными, если это опасно для класса — не грамотно, по крайней мере это распространенное мнение, спорить с которым бесполезно.

Ровно так же опасно объявлять поля protected.

V>Однако, полностью перекрыть доступ для потенциальных наследников может сказаться на эффективности,

Уж если ты начал корежить архитектуру в угоду эффективности, то ты сам себе злобный буратина, и не надо на наследование пенять. Ровно той же эффективностью некоторые товарищи оправдывают выставление полей в публичный интерфейс.

V>>>Не всякий класс дотнета является компонентом.

AVK>>Всякий.
V>Абстракный — не компонент.

Почему?

V>Не наследующий IComponent не может визуально обрабатываться студией,

Блин, ну что за повальное маньячество — IComponent классом реализуется.
Не студией, а конкретной реализацией дизайнера, я тебе даже больше скажу, если ты даже реализуешь его, дизайнер все равно с ним работать не будет. А вот к примеру PropertyGrid с успехом может отображать любой класс. Ровно как я могу написать дизайнер, так же успешно без IComponent обходящийся.

V> т.е. не выполняет задачи компонента: бинарное распространение и автоматизированное использование (ручками я могу равнотрудоемко и сорсы использовать).

Выполняет, тут имхо сказывается твое незнание дотнета.

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

AVK>>Раньше по другому было нельзя.

V>в Линухе нет, в "больших" юнихах — да

Речь то шла о Линухе, не так ли?

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

AVK>>GDI+

V>тогда уж GdiPlus,
V>GDI+ — маркетинговое название

Нет, это GdiPlus название файла, поскольку значок + в имени файла недопустим. Вот к примеру комментарий из хидера

/**************************************************************************\
*
* Copyright (c) 1998-2001, Microsoft Corp. All Rights Reserved.
*
* Module Name:
*
* Gdiplus.h
*
* Abstract:
*
* GDI+ public header file
*
\**************************************************************************/

AVK>>Нет. Это даже не дотнет.
V>ну блин, тогда и Windows.Forms не дотнет, ибо стандартные контролы — это роперы над нативными контролами вынь.

Не совсем. В WinForm есть немало чисто managed функционала, в тоом числе и полностью managed компоненты, да и интерфейс совершенно другой. А вот System.Drawing это практически чистая обертка.

AVK>>System.Drawing?
V>угу, разве это не к ГУИ относится?

Относится. И что?

AVK>>Совсем не похоже. Винформсы это скорее новая реинкарнация VCL.

V>Я не по духу, а по имплементации:
V>

V>public class Control : Component, UnsafeNativeMethods.IOleControl, UnsafeNativeMethods.IOleObject, 
V>UnsafeNativeMethods.IOleInPlaceObject, UnsafeNativeMethods.IOleInPlaceActiveObject, 
V>UnsafeNativeMethods.IOleWindow, UnsafeNativeMethods.IViewObject, UnsafeNativeMethods.IViewObject2, 
V>UnsafeNativeMethods.IPersist, UnsafeNativeMethods.IPersistStreamInit, UnsafeNativeMethods.IPersistPropertyBag, 
V>UnsafeNativeMethods.IPersistStorage, UnsafeNativeMethods.IQuickActivate, ISupportOleDropSource, IDropTarget, 
V>ISynchronizeInvoke, IEnablable, IWin32Window, IArrangedElement, IBindableComponent, IComponent, IDisposable
V>

V>это стандартный ActiveX

Это означает что Control реализует ole-интерфейсы. Однако все эти IOleControl реализованы явно, и напрямую, а так же в managed коде не используются. Архитектура у WinForms собственная. Если грохнуть реализацию всех этих интерфейсов все будет прекрасно работать, просто нельзя будет хостить дотнетные контролы в IE или MFC Host.

V>>>Заодно "попутно" получили совместимость с де-факто существующей тонной ActiveX-компонентов, что на начальных этапах "раскрутки" технологии давало немало дополнительных очков...

AVK>>Нет там никакой такой совместимости — все взаимодействие через обертки.

V>речь не о декларируемых интерфейсы COM-объекта, а именно про его поднаготную, IOleControl, IOleObject, IViewObject, IOleWindow, и т.д.

Это не подноготная, это как раз и есть интерфейсы AX контрола.

V>С этой штукой Windows.Forms работают так же как и со своими "родными" контролами.

Нет. Ты бы все таки посмотрел что там происходит при импорте AX, прежде чем подобное утверждать. Создается новый managed-контрол, который транслирует все вызовы в managed-вариант. ВинФормс все эти замечательные СОМовские потроха напрямую не использует.