По мотивам - http://18delphi.blogspot.ru/2013/10/interlockedincrementinterlockeddecrement.html?showComment=1382650171837#c3431462197280892242
Протоколы vs интерфейсы.
Это кстати - ГЕНИАЛЬНАЯ идея.
На месте разработчиков компиляторов/языков я бы к ней прислушался бы.
TmyObject = class(TParent, IInterface)
end;
vs.
TmyObject = class(TParent, protocol PProtocol)
end;
Что в итоге?
Supports(myObject, IInterface, l_Interface);
-- тут взводится счётчик ссылок..
GetProtocol(myObject, PProtocol, l_Protocol); (и БЕЗ ВСЯКИХ QueryInterface, только лишь аналог GetInterface)
-- тут НЕ взводится счётчик ссылок.. Да и - НЕЗАЧЕМ.
Объяснять - ПОЧЕМУ?
P.S. Duck-typing только БЕЗ Duck-typing'а. ДАВНО мне такого не хватает.
Протоколы vs интерфейсы.
Это кстати - ГЕНИАЛЬНАЯ идея.
На месте разработчиков компиляторов/языков я бы к ней прислушался бы.
TmyObject = class(TParent, IInterface)
end;
vs.
TmyObject = class(TParent, protocol PProtocol)
end;
Что в итоге?
Supports(myObject, IInterface, l_Interface);
-- тут взводится счётчик ссылок..
GetProtocol(myObject, PProtocol, l_Protocol); (и БЕЗ ВСЯКИХ QueryInterface, только лишь аналог GetInterface)
-- тут НЕ взводится счётчик ссылок.. Да и - НЕЗАЧЕМ.
Объяснять - ПОЧЕМУ?
P.S. Duck-typing только БЕЗ Duck-typing'а. ДАВНО мне такого не хватает.
>>Объяснять - ПОЧЕМУ?
ОтветитьУдалитьОбязательно!
Хороша ли неявная типизация? Является ли она следствием невозможности (во всех смыслах) воссоздать наследственную связь понятий?
Т.е. мы, знатоки кода, отказываем человеческому разуму в способности применить отображение реального мира на картину в сознании относительно программных единиц?
Я бы даже сказал, что "не объяснять", а "иллюстрировать" надо. Проблематика инженерных практик в том, чтобы "палкой и верёвкой" решить текущие задачи функциональной поддержки. Я уже боролся с этим :)
Определение "потребительских" качеств объекта по формальным признакам важно. Будет ли этим формальным набором "генетика" класса объекта, соответствие сигнатуре, доливом интерфейса или поддержкой некого протокола - вопрос красоты реализации в контексте разработке и сопровождения кода. Полезность красоты подтверждается сокращением времени в рамках компетенции конкретного специалиста - вот главный вопрос. Если по иерархии сознание "скользит" в рамках привычных схем (включая поддерживающие графические нотации), то неявная типизация порождает некие кульбиты мозга. Выходит на поверхность задача "распознавания". Оно нам надо?
Ответ в конкретном примере, если Вы, Александр, дадите нам ситуацию применения.
Пока ситуация выглядит так. Сначала мы с головой окунаемся в разрушение иерархий (=отказ от графичеких нотаций, иначе как неявная типизация будет выглядеть? если она динамическая и не определяется структурой кода - что будем рисовать? пунктирную линию в никуда?). Потом придумываем методы проверки этой типизации. Потом сетуем на то, что отсутствуют стандартные методы решения коррекции проблем в мышлении?
Я начинаю думать о полезности разделения моделей по функциональному признаку - пусть будет MVC. Пусть интерфейсное (пользовательско-интерфейсное) представление будет "объект, как пользователь его видит", а где-то глубоко в памяти (компьютера) будет "объект, как он представляется относительно предметной области".
И далее выплывает другой момент: а что главнее? То, как потребитель видит оъект И управляет его поведением, или же квази-реальный объект? Может, тогда не стоит "надумывать", а реально физиологически задавать жёсткие конструкции?
Или суть поста - лишь побороть "взведение ARC-а"? Мы оставляем право взвести курок, но не производить выстрел?
Всеволод, отвечу. Чуть позже. Много вопросов задали. А я сейчас "в другом мире". Мире xCode. Сложно мозги переключать. Я немного написал в блоге. Но это далеко не полный ответ.
Удалить"Или суть поста - лишь побороть "взведение ARC-а"?"
Удалить-- суть поста - СОВСЕМ не в этом.
"Я начинаю думать о полезности разделения моделей по функциональному признаку - пусть будет MVC. Пусть интерфейсное (пользовательско-интерфейсное) представление будет "объект, как пользователь его видит", а где-то глубоко в памяти (компьютера) будет "объект, как он представляется относительно предметной области". "
УдалитьЛогично :-) Если я правильно вас понял :-)
"Определение "потребительских" качеств объекта по формальным признакам важно. Будет ли этим формальным набором "генетика" класса объекта, соответствие сигнатуре, доливом интерфейса или поддержкой некого протокола - вопрос красоты реализации в контексте разработке и сопровождения кода. Полезность красоты подтверждается сокращением времени в рамках компетенции конкретного специалиста - вот главный вопрос. Если по иерархии сознание "скользит" в рамках привычных схем (включая поддерживающие графические нотации), то неявная типизация порождает некие кульбиты мозга. Выходит на поверхность задача "распознавания". Оно нам надо?"
УдалитьВо-первых - про НЕЯВНУЮ типизацию - никто не говорил. Говорил как раз про ЯВНУЮ. :-)
Во-вторых - ДАЖЕ НЕЯВНАЯ типизация на чертежах (слово UML - с некоторых пор - я стараюсь изживать из лексикона) - рисуется.
В-третьих - я вот ОТНЮДЬ НЕ СТОРОННИК неявной типизации :-) Скорее - противник. Она да - где-то решает "локальные задачи". Но ставить "во главу архитектуры" её как в xCode или Python - считаю ПРИНЦИПИАЛЬНОЙ ошибкой.
Кстати - проще бы встретиться :-) Я вот коллеге сегодня тезисы в курилке за 5 мин изобразил.
"если она динамическая и не определяется структурой кода - что будем рисовать? пунктирную линию в никуда?"
УдалитьЕщё "куда КУДА" :-) считайте это "вбросом" :-)