Почему записи Delphi не могут иметь наследования?
Что-то я задавался вопросом в течение долгого времени: почему записи Delphi не в состоянии иметь наследование (и таким образом все другие важные функции OOP)?
Это по существу сделало бы записи выделенной стеку версией классов, точно так же, как классы C++, и представит "объекты" (примечание: не экземпляры) устаревший. Я не вижу ничего проблематичного с ним. Это также было бы хорошей возможностью реализовать предописания для записей (который я все еще экранирован относительно того, почему она все еще отсутствует).
Вы видите какие-либо проблемы с этим?
7 ответов
, относящийся к этому вопросу, есть два вида наследования: наследование интерфейса и наследования реализации.
Наследование интерфейса в целом подразумевает полиморфизм. Это означает, что если B получена из A, то значения типа B могут храниться в местах типа A. Это проблематично для типов значений (например, записей), в отличие от типов ссылок из-за нарезки. Если B больше, чем A, а затем хранить его в расположении типа A, укорется значение - любые поля, которые B добавляются в его определении, и выше, которые будут потеряны.
Наследование реализации менее проблематично с этой точки зрения. Если бы Delphi имел запись наследства, но только из реализации, а не интерфейса, все не было бы слишком плохим. Единственная проблема заключается в том, что просто создание значения типа A поле типа B делает большую часть того, что вы хотели бы вне реализации наследования.
Другой вопрос - виртуальные методы. Диспетчер Virtual Method требует какой-то бирку для каждого значения, чтобы указать тип выполнения значения, так что правильный переопределенный метод можно обнаружить. Но учетные записи не имеют никакого места для хранения этого типа: поля записи - это все поля. Объекты (старый вид Turbo Pascal) могут иметь виртуальные методы, потому что у них есть VMT: первый объект в иерархии для определения виртуального метода, неявно, добавляет VMT до конца определения объекта, выращивая его. Но объекты Turbo Pascal имеют одинаковую проблему нарезания, описанную выше, что делает их проблематичными. Виртуальные методы на типов ценностей эффективно требуют наследования интерфейса, что подразумевает проблему нарезки.
Таким образом, чтобы правильно поддерживать наследство рекорантов наследования интерфейса, нам нужно какое-то решение проблемы нарезки. Бокс был бы одним видом решением, но он обычно требует использования сборки мусора, и он ввел бы неоднозначность на язык, где это может быть не понятно, работаете ли вы со значением или ссылкой - немного похоже на целое число VS Int в Java с автообоксином. По крайней мере, в Java есть отдельные имена для бокселей VS Unboxed «Видных видов» типов значений. Еще один способ сделать бокс - это как Google Go с его интерфейсами, который является своего рода наследование интерфейса без наследования реализации, но требует определения интерфейсов отдельно, и все места интерфейса являются ссылками. Типы значений (E.G. Записи) входят в систему, когда упоминаются ссылка на интерфейс. И, конечно же, уходит также имеет сборку мусора.
Записи и классы / объекты являются двумя совершенно разными вещами в Delphi. В основном рекорд Delphi представляет собой C struct - Delphi даже поддерживает синтаксис, чтобы подобные вещи, подобные имеют запись, доступ к которому можно получить доступ как либо 4 16-битных целых чисел, либо на 2 32-битных целых числа. Как правило struct , , Record датируется до того, как перед объектом ориентированное программирование введено в язык (ERA Pascal).
Как и структура, запись также является встроенным ломкой памяти, а не указатель на кусок памяти. Это означает, что когда вы передаете запись в функцию, вы передаете копию, а не указатель / ссылку. Это также означает, что когда вы объявляете переменную типа записи в вашем коде, он определяется при компиляционном времени, насколько большой - - переменные типа записи, используемые в функции, будут выделены на стеке (не как указатель на стеке, а как Структура байта 4, 10, 16 и т. Д.). Этот фиксированный размер не играет хорошо с полиморфизмом.
Поскольку записи не имеют VMT (таблица виртуального метода).
http://zargony.com/2009/07/24/ruby-1-9-and-file-encodings
Не путайте кодировку файлов и кодировку последовательности!
-121--1681451-Простой случай: aa.
Более сложный случай: aaaa.
И так далее.
-121--4533740-Единственная проблема, которую я вижу (и я могу быть недальновидным или неправильным), это цель. Записи предназначены для хранения данных, а объекты - для манипулирования и использования этих данных. Почему шкафчик для места хранения данных нуждается в процедурах манипулирования?
можно также использовать «$ baseName '_ $ count $ Ext»
-121--2501861-Вам нужен этот API: http://code.google.com/apis/ajaxsearch/local.html
Также проверьте следующее: http://googleajaxsearchapi.blogspot.com/2007/06/local-search-control-for-maps-api.html
-121--4998427-В прошлом я использовал объекты (а не классы!) в качестве записей с наследованием.
В отличие от того, что некоторые люди здесь говорят, что для этого есть законные причины. Дело, которое я сделал, касалось двух структур из внешних источников (API, а не ничего с диска - мне нужна была полностью сформированная запись в памяти), вторая из которых просто продлила первую.
Такие случаи очень редки.
Вы правы, добавление наследства записей, по существу, повернет их в классы C ++. И это твой ответ прямо там: это не сделано, потому что это было бы ужасной вещью. Вы можете иметь выделенные стеками значения значений, или вы можете иметь классы и объекты, но смешивание двух - очень плохое представление. Как только вы сделаете, вы окажетесь со всеми видами вопросов управления пожизненным управлением и в конечном итоге должны построить уродливые хаки, такие как C ++ Raii Pattern на язык, чтобы иметь дело с ними.
Нижняя строка: если вы хотите, чтобы тип данных можно унаследовать и расширен, использовать классы. Это то, что они там.
Отредактируйте: В ответ на вопрос облака это не то, что можно продемонстрировать через один простой пример. Весь объектная модель C ++ - это катастрофа. Это может не выглядеть как один конец; Вы должны понимать несколько взаимосвязанных проблем, чтобы действительно понять большую картину. Райи просто беспорядок в верхней части пирамиды. Может быть, я напишу более подробное объяснение моего блога позже на этой неделе, если у меня будет время.
Вы можете попробовать использовать объект Delphi ключевое слово для этого. Те, кто в основном наследуется, но ведут себя гораздо больше похожи на записи, чем к занятиям.