о типах (программистское)

[avva]

Я искренне пытался понять эту статью, сравнивающую объекты и абстрактные типы данных, но в итоге всего лишь сломал мозг. Основной аргумент мне кажется то ли невнятным, то ли очевидно неверным. В результате ее прочтения я решил, что объекты и ADTs более похожи друг на друга, чем до того считал (т.е. пришел к выводу, противоположному утверждениям статьи).

Скорее всего, виноват я, а не автор, и у меня просто не получается понять, что он говорит (главным образом, когда он говорит об OOP). Кстати, если вы понимаете эту статью и согласны с ней, я был бы рад задать вам пару вопросов. Короче, основным результатом моей фрустрации стало то, что я начал читать Types and Programming Languages Пирса. Вот прочитаю и буду все знать про типы. Пока что очень нравится, отлично объясняет и заинтересовывает. Кстати, обнаружился черновик русского перевода. Мне он ни к чему, но может кому-то пригодится.

Comments

[laformica.livejournal.com]

Какая-то каша, если честно. "Классы могут отсутствовать как класс" - не понимаю.

И вообще, по-моему еще со времен древней греции известно, что прежде, чем что-то сравнивать, надо это определить. Соглашаться с Мейером или нет, но по крайней мере он дает точные и однозначные определения, которыми лично я пользуюсь.
Вот нашел и для ADT:

DT is a set of data values and associated operations that are precisely specified independent of any particular implementation.

Я правильно понимаю, что за всю статью автор так и не удосужился таки объяснить, что лично он понимает под каждым термином?

Еще раз, это те определения, которыми пользуюсь я. Если вы можете поделиться определениями того, что вы понимаете под словами ADT, object и class, то я готов продолжить беседу. Если нет - то я не вижу и смысла.

Вообще у меня сложилось впечатление, что вы под object понимаете reference type, а под adt - value type.

[(Anonymous)]

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

Насколько я могу судить, понимание adt как value type довольно близко к позиции автора статьи, но не идентично.

[laformica.livejournal.com]

Почитал. Мое мнение: наукообразная ересь.

По существу вопроса: я не понимаю данную статью и не согласен с ней. Не понимаю, потому что автор статьи не способен излагать свои мысли просто и структурно. По-моему он просто дрочит на те 62 источника, на которые ему удалось сослаться.

Не согласен, потому что несмотря на ссылки на 62 источника, совершенно непонятно, на что он ссылается, заявляя, что

built-in types in most languages... are abstract data types

если это его собственное определение, то оно отличается от того, чем пользуюсь я.

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

Суть вашего ответа я понял так, что данная статья намного менее спорная, чем труд Мейера, на которого ссылается ни много ни мало Гради Буч, и что вы ее прекрасно поняли (и даже нашли некий пафос) и способны объяснить, почему же она стоит того, чтобы ее вообще читать. И это меня заинтересовало.
Но так как вы излагаете свои мысли еще немного менее понятно, чем автор статьи, для начала я решил узнать, что вы понимаете под теми терминами, которые используете.

В итоге я остаюсь с мнением, что некоторым просто гораздо приятнее рассуждать о том, насколько очевидным для них кажется то, что другим ломает мозг, чем в двух словах донести до этих последних очевидное.

[(Anonymous)]

Ну вот, хотел в двух словах, а написал столько, что даже заглавные буквы пришлось расставить, чтобы уж совсем было все как положено.

built-in types in most languages... are abstract data types

Это не определение, а наблюдение. Определение было предложением раньше. Вот оно еще раз: An abstract data type (ADT) has a public name, a hidden representation, and operations to create, combine, and observe values of the abstraction.

Может быть, Вы его не узнали в гриме, но это именно определение. Сущность определяется набором свойств, которым эта сущность обладает. Припоминая давно забытое, рискну предположить, что такие определения через набор свойств называются в математике аксиоматическими. Если у чего-то есть публичное имя, скрытое представление и набор операций, то это что-то — абстрактный тип. Далее уточняется, что представление у абстрактного типа в рамках одной программы (модуля и т.п.) единственное. Это важно не для пользователя типа (пользователь представления не видит), а для его автора (автор видит).

Наблюдение утверждает, что, например, тип Integer в языке Паскаль имеет публичное имя (ставим галочку), скрытое представление (галочку) и набор операций для манипуляции значениями (галочку). Если принять предложенное определение, то я не очень понимаю, с чем здесь спорить. Разве что с тем, что пользователь не знает, единственное ли там представление — для этого нужно в компилятор лезть и смотреть, как Integer реализован. Но логика и опыт написания компиляторов подсказывают, что скорее всего все-таки единственное.

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

Это как раз то, что автор называет object interface.

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

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

И все. Ну что здесь такого спорного или непонятного, а?

Здесь несколько больше, чем два слова, но я надеюсь, что очевидное-тривиальное худо-бедно донесено и не расплескано по дороге.

[laformica.livejournal.com]

О, вот теперь я вас понимаю. И, о чудо, я понимаю и автора статьи. Хотя понимать ее уже даже не надо, потому что, по моему, суть вы прекрасно изложили здесь. За что спасибо.

Все-таки невозможно читать текст, если под используемыми терминами понимаешь абсолютно другие вещи. Вот для меня, повторюсь, но своими словами, АТД - это набор характеристик и поведения, присущий некоторому множеству объектов предметной области; класс - это то же самое, но описанное в синтаксисе конкретного языка программирования + имплементация, а объект - структура времени исполения, представляющая объект предметной области, обладающая собственными значениями описанных характеристик, и к которой применимы операции, описываемые поведением.
Тип Integet в языке Паскаль, я кажется называю "элементарный тип".

Для меня речь о том, фиксированно представление или нет на данном уровне не идет. И тем более для меня странно, что объект для автора это всего-лишь пачка процедур, без какого-либо состояния (или состояние он игнорирует в рамках статьи? или оно неявно определено множеством возвращаемых значений его процедур?).

Интересно, что если посмотреть, какие определения неправильны с точки зрения автора, а именно “A class is itself an abstract data type” и “the abstract data types in object-oriented languages... are called classes.”, то они более или менее совпадают с моими.

Мне искренне интересно, как так выходит, что у нас такая принципиально разная терминология? Я, откровенно говоря, полагал, что уж тут на сегодняшний день не может быть никаких разночтений.

В итоге, апдейт вывода о статье: ну раз автор называет словами ADT и object именно то, что он называет, спорить, действительно, не о чем. Различие, действительно, есть, различие существенное, чтобы о нем помнить, хотя бы изучая новый язык программирования. В общем, тогда не ересь. Но и не более того.

[(Anonymous)]

1. Я, например, познакомился с абстракцией данных через язык CLU (да, я такой старый), в котором АТД определяются как в статье (на самом деле наоборот, в статье как в CLU). Так что терминология мне вполне близка. Тому, кто начал изучение с ООП, она может показаться странной.

2. Наличие или отсутствие mutable state вполне ортогонально предмету разговора. Для простоты можно считать, что методы принимают состояние объекта и возвращают новое состояние. Так обычно принято.

[(Anonymous)]

Кстати, на статью Кука ссылается Гай Стил, человек тоже не последний в дизайне языков программирования.
http://projectfortress.sun.com/Projects/Community/blog/ObjectOrientedTailRecursion