Господа, такой вопрос:
1. корректно ли сказать, что динамическая типизация по сравнению со статической — это замена отношения "is-a" отношением "can"?

Т.е., очень обобщенно говоря, два значения вступают между собой в некоторые отношения, скажем:

a.function(b);

Для статической типизации — нужно отношение is-a:

class A
{
    void function(B _b)//чтобы установить отношения a.function(b), должно выполняться соотношение b is-a B
    {
        _b.foo();
    }
}

Для динамической — нужно отношение can:

class A
    def function(b)  //чтобы установить отношения a.function(b), не должно выполняться никаких соотношений, но...
        b.foo;       //...вот здесь потребуется соотношение b can foo

Это единственное отличие динамической типизации от статической?
Если да, то вопрос:
2. Если среда (компилятор, IDE) проверяет отношения can в design-time — это какая типизация — динамическая или статическая?

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Господа, такой вопрос:
ЗХ>1. корректно ли сказать, что динамическая типизация по сравнению со статической — это замена отношения "is-a" отношением "can"?

ЗХ>Т.е., очень обобщенно говоря, два значения вступают между собой в некоторые отношения, скажем:
ЗХ>

ЗХ>a.function(b);
ЗХ>

ЗХ>Для статической типизации — нужно отношение is-a:

ЗХ>Для динамической — нужно отношение can:
ЗХ>

ЗХ>class A
ЗХ>    def function(b)  //чтобы установить отношения a.function(b), не должно выполняться никаких соотношений, но...
ЗХ>        b.foo;       //...вот здесь потребуется соотношение b can foo
ЗХ>

Как мне кажется, тут ты привёл пример не динамической типизации, а отсутствия типизации как таковой... То есть отношение can — это скорее для языков без типизации, нежели для языков с динамической типизацией... Разница между ними очень тонкая. Пример ОО языка с динамической типизацией: Smalltalk. Пример ОО языка без типизации: Self. Отличия: у объектов языка с динамической типизацией тип всё же есть, он определяется в ран-тайме, но он есть. По идее проверку типа можно выполнить уже при передаче объекта, а не при вызове метода и точно знать пройдут все последующие вызовы или нет, то есть имеем всё таки is-a. А вот для языков без типизации характерно именно отсуствие какого либо типа у объектов. На практике это выражается тем, что один и тот же объект может менять свой "интерфейс" динамически — добавлять и удалять методы и поля (слоты в терминалогии Self) во время выполнения. То есть в разные моменты времени для такого объекта вызов foo может как отклониться, так и пройти и проверить это при передаче объекта невозможно. То есть в данном случае как раз отношение can.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>1. корректно ли сказать, что динамическая типизация по сравнению со статической — это замена отношения "is-a" отношением "can"?

Может лучше "like-a" ?

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

ЗХ>>1. корректно ли сказать, что динамическая типизация по сравнению со статической — это замена отношения "is-a" отношением "can"?

E>Может лучше "like-a" ?

Неа, не похоже Нет сущности, которую можно было бы поставить справа от like-a.

А как насчет ответа на второй вопрос?

Здравствуйте, Зверёк Харьковский, Вы писали:


ЗХ>Это единственное отличие динамической типизации от статической?

Ты путаешь *типизацию* и *статическую типизацию*.

Статическая типизация — правила типизации проверяются на этапе компиляции.
Динамическая типизация — правила типизации проверяются на этапе выполнения.
Сильная типизация — правила типизации энфорсятся всегда.
Слабая типизация — правила типизации энфорсятся с заранее оговоренными
исключениями

(с)_vovin здесь

Автор: _vovin
Дата: 04.03.05

С уважением, Gleb.

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

MN>Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>>Господа, такой вопрос:
ЗХ>>1. корректно ли сказать, что динамическая типизация по сравнению со статической — это замена отношения "is-a" отношением "can"?

ЗХ>>Т.е., очень обобщенно говоря, два значения вступают между собой в некоторые отношения, скажем:
ЗХ>>

ЗХ>>a.function(b);
ЗХ>>

ЗХ>>Для статической типизации — нужно отношение is-a:

ЗХ>>Для динамической — нужно отношение can:
ЗХ>>

ЗХ>>class A
ЗХ>>    def function(b)  //чтобы установить отношения a.function(b), не должно выполняться никаких соотношений, но...
ЗХ>>        b.foo;       //...вот здесь потребуется соотношение b can foo
ЗХ>>

MN>Как мне кажется, тут ты привёл пример не динамической типизации, а отсутствия типизации как таковой... То есть отношение can — это скорее для языков без типизации, нежели для языков с динамической типизацией... Разница между ними очень тонкая. Пример ОО языка с динамической типизацией: Smalltalk. Пример ОО языка без типизации: Self. Отличия: у объектов языка с динамической типизацией тип всё же есть, он определяется в ран-тайме, но он есть. По идее проверку типа можно выполнить уже при передаче объекта, а не при вызове метода и точно знать пройдут все последующие вызовы или нет, то есть имеем всё таки is-a. А вот для языков без типизации характерно именно отсуствие какого либо типа у объектов. На практике это выражается тем, что один и тот же объект может менять свой "интерфейс" динамически — добавлять и удалять методы и поля (слоты в терминалогии Self) во время выполнения. То есть в разные моменты времени для такого объекта вызов foo может как отклониться, так и пройти и проверить это при передаче объекта невозможно. То есть в данном случае как раз отношение can.

Я возражу. По моему мнению Self настолько же строго типизирован, как и Smalltalk.
Поясню мысль.
Динамическая типизация — контроль типов осуществляется во время выполнения.
Сильная типизация — правила типизации выполняются всегда.
Что такого различного в Smalltalk и Self, что может повлиять на типизацию?
Как уже было сказано — это возможность Self динамически менять поведение объектов модифицируя таким образом "типы", к которым он относится.
Но если присмотреться, такая возможность отлично ложится под определение динамической типизации (которая ортогональна сильной-слабой типизации). Ведь динамический контроль типов и состоит в том, чтобы контроль осуществлять *в момент вызова*. А то, что объект модифицирует свое поведение за время своей жизни, является лишь еще одним измерением динамичности системы.
Smalltalk отличается лишь тем, что типы его объектов фиксированы на момент создания/загрузки приложения. Но в определении сильной типизации про неизменность типов ничего не сказано. Сказано лишь, что объект одного типа не может быть интерпретирован как объект другого типа. Т.е. этот инвариант действует *только лишь в момент* выполнения операции с объектом.
Если уж на то пошло, Smalltalk обладает точно такими же средствами модификации структуры/поведения во время выполнения. Просто они не выставлены так явно как в Self. Иначе на Smalltalk невозможно было бы реализовать собственные средства разработки. [Напоминаю, что в Smalltalk программы создаются не как набор исходных текстов с дальнейшей их трансляцией, а посредством манипулирования объектами-классами с прозрачным внесением изменений во все созданные объекты-экземпляры].

Теперь если задать вопрос, какой язык можно назвать бестиповым?
Думаю таких языков не существует. Любой язык состоит из операций, которые работают с данными определенного типа.
Тот же ассемблер, где типы различаются по размерности, знаковости, целое/плавающее число и т.д.
А вот то, что любые данные могут быть интерпретированы как данные другого типа — это в точности слабая типизация.
Другой пример слабой типизации — сложение строк с числами, использование строк как числовых значений (например как индекс в массиве), и т.д.

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

MN>Как мне кажется, тут ты привёл пример не динамической типизации, а отсутствия типизации как таковой... То есть отношение can — это скорее для языков без типизации, нежели для языков с динамической типизацией... Разница между ними очень тонкая. Пример ОО языка с динамической типизацией: Smalltalk. Пример ОО языка без типизации: Self. Отличия: у объектов языка с динамической типизацией тип всё же есть, он определяется в ран-тайме, но он есть.

Это только до тех пор пока не пишем всякие (вполне нормальные для Smalltalk) извращения. Например, b class определяет doesnotUndestand:, а вместо a.fuction написано a perform: methodName. Или с помощью become:, меняем класс b на ходу.

MN>По идее проверку типа можно выполнить уже при передаче объекта, а не при вызове метода и точно знать пройдут все последующие вызовы или нет, то есть имеем всё таки is-a. А вот для языков без типизации характерно именно отсуствие какого либо типа у объектов. На практике это выражается тем, что один и тот же объект может менять свой "интерфейс" динамически — добавлять и удалять методы и поля (слоты в терминалогии Self) во время выполнения. То есть в разные моменты времени для такого объекта вызов foo может как отклониться, так и пройти и проверить это при передаче объекта невозможно. То есть в данном случае как раз отношение can.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>>>1. корректно ли сказать, что динамическая типизация по сравнению со статической — это замена отношения "is-a" отношением "can"?

E>>Может лучше "like-a" ?

ЗХ>Неа, не похоже Нет сущности, которую можно было бы поставить справа от like-a.

Это почему же? if it walks <b>like a</b> <i>duck</i>, and talks <b>like a</b> <i>duck</i>, then it might as well be a duck

ЗХ>А как насчет ответа на второй вопрос?

Боюсь, что это не ко мне. Я все же больше практик, чем теоретик.
Но вот, что мне кажется: если какие-то проверки делает компилятор (контракта там, или интерфейса, или типа), то это статическая типизация. Если же такие проверки делает не компилятор, а run-time (интрпритатор), то это уже получается динамическая типизация.

А IDE вполне может что-то проверять и подсказывать. На основании каким-то образом описанных эвристик. Например, на сайте Ruby On Rails есть видео-демка (15m intro video (50MB)), в которой показано использование какого-то редактора, понимающего Ruby (очень похоже на TextMate). Так вот этот редактор специальным образом подсвечивает методы, относящиеся к Rails (может он анализирует require или методы классов в тех же каталогах/подкаталогах, может в нем это просто зашито). Тем не менее, Ruby остается интерпритируемым динамическим языком.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Господа, такой вопрос:
ЗХ>1. корректно ли сказать, что динамическая типизация по сравнению со статической — это замена отношения "is-a" отношением "can"?

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

Таким образом при динамической типизации (или если более корректно при латентной типизации) возникает смещение точки зрения — тип объекта как абстракция порождается со стороны использования, а не структурой самого объекта.
Т.е. если кто-то вызвал у объекта только лишь метод #doThis, то значит появляется динамический тип SomeAbstraction с единственным методом #doThis.
Понятное дело, что объект должен знать варианты его использования, чтобы корректно реализовать в себе требуемую функциональность. Но, в то же время, кто-то может захотеть использовать подмножество протокола какого-то типа, реализуемого объектом. В этот момент можно вывести новый тип как подмножество исходного, и он может быть реализован в других объектах без необходимости менять исходный.
Ну например.
Есть некий алгоритм, которому на вход подается коллекция, у которой вызывается метод #contains: для определения принадлежности коллекции некоторого объекта:

someAlgorithmOn: aCollection
    ...
    found := aCollection contains: xxx.
    ...

Потом допустим всплывает новое требование, которое можно реализовать, передавая объект, всегда отвечающий true на #contains:.
Для этого мы вводим новую абстракцию под названием например MinimalContainer и создаем класс MinimalContainerUniverse с необходимой реализацией.

MinimalContainerUniverse
    contains: anElement
        ^true

someAlgorithm: aMinimalContainer
    ...
    found := aMinimalContainer contains: xxx.
    ...

В случае же манифестной типизации пришлось бы сделать одно из:
1) Вывести интерфейс MinimalContainer и прописать его в классе коллекции. Если это стандартная коллекция, то пришлось бы для этого унаследоваться. Но если проконтролировать ее создание нельзя, тогда такой вариант не пройдет.
2) Реализовать весь интерфейс Collection в своем классе CollectionUniverse. Только что делать с остальными методами? Прописать OperationNotSupportedException? Тогда в жертву приносится статический контроль типов.

ЗХ>Это единственное отличие динамической типизации от статической?
ЗХ>Если да, то вопрос:
ЗХ>2. Если среда (компилятор, IDE) проверяет отношения can в design-time — это какая типизация — динамическая или статическая?

Динамическая. С оговоркой, что только лишь если все отношения достоверно проверить нельзя.

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

ЗХ>>Это единственное отличие динамической типизации от статической?
GZ>

GZ>Ты путаешь *типизацию* и *статическую типизацию*.

GZ>Статическая типизация — правила типизации проверяются на этапе компиляции.
GZ>Динамическая типизация — правила типизации проверяются на этапе выполнения.
GZ>Сильная типизация — правила типизации энфорсятся всегда.
GZ>Слабая типизация — правила типизации энфорсятся с заранее оговоренными
GZ>исключениями

GZ>(с)_vovin здесь

Автор: _vovin
Дата: 04.03.05

Пытаюсь разобраться... Т.е. для моего примера
[code]
class A
{
void function(B _b); //все равно нужно задать, к какому типу должен относиться аргумент
}

...
a.function(b);//но вот относится ли он к этому типу — может меняться динамически, в run-time
...
[code]

Так?

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Пытаюсь разобраться... Т.е. для моего примера
ЗХ>

ЗХ>class A
ЗХ>{
ЗХ>    void function(B _b);  //все равно нужно задать, к какому типу должен относиться аргумент
ЗХ>}

ЗХ>...
ЗХ>a.function(b);//но вот относится ли он к этому типу - может меняться динамически, в run-time
ЗХ>...
ЗХ>

ЗХ>Так?

Это пример какой типизации?

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

ЗХ>>Господа, такой вопрос:
ЗХ>>1. корректно ли сказать, что динамическая типизация по сравнению со статической — это замена отношения "is-a" отношением "can"?

_>Именно так. Только динамическая еще говорит, что типы всех выражений в программе могут быть определены только на этапе выполнения.
_>Поэтому на этапе компиляции не осуществляется проверка (или по-крайней мере не все проверки) на возможность вызова того или иного метода.

Во! Начинает проясняться! А как насчет людей, который опровергают это утверждение, цитируюя тебя же?

ЗХ>>Это единственное отличие динамической типизации от статической?
ЗХ>>Если да, то вопрос:
ЗХ>>2. Если среда (компилятор, IDE) проверяет отношения can в design-time — это какая типизация — динамическая или статическая?

_>Динамическая. С оговоркой, что только лишь если все отношения достоверно проверить нельзя.

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

a.function(b);

далеко не всегда даже полный анализ программы в design-type покажет, какого же типа тут будет b.
Так?

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

Со всем согласен.
_>Теперь если задать вопрос, какой язык можно назвать бестиповым?
Этот термин иногда употребляют как синоним "динамически типизированный". Мне лично это не нравится, но такова жизнь.

А вот если бы мне дали выбирать смысл этого термина, то... язык, в котором понятие "типа" отсутствует в принципе, оно в язык не введено. Примеры — язык FORTH, и ассемблер. При этом, несмотря на отсутствие понятия типа в языке, думать о типах программисту никто не запрещает. Как говорил Трурль, "типы существуют только в воображении программиста". Хорошо сказано, точно отражает суть.

При этом, смаллток, С и LISP я бы "бестиповыми" не назвал.

Но! Мне выбирать смысл термина "бестиповый язык" никто не дает . Поэтому, лучшее, что я могу сделать — не употреблять его вообще. Во избежание. Чего и тебе советую.

_>Думаю таких языков не существует. Любой язык состоит из операций, которые работают с данными определенного типа.
_>Тот же ассемблер, где типы различаются по размерности, знаковости, целое/плавающее число и т.д.

Да. Только в воображении программиста .

_>А вот то, что любые данные могут быть интерпретированы как данные другого типа — это в точности слабая типизация.
+1

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

ЗХ>>Так?

_>Это пример какой типизации?
Да я уже сам перестал понимать...

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

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

G>Но! Мне выбирать смысл термина "бестиповый язык" никто не дает . Поэтому, лучшее, что я могу сделать — не употреблять его вообще. Во избежание. Чего и тебе советую.

Подписываюсь под каждым словом.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Пытаюсь разобраться... Т.е. для моего примера
ЗХ>

ЗХ>class A
ЗХ>{
ЗХ>    void function(B _b);  //все равно нужно задать, к какому типу должен относиться аргумент
ЗХ>}

ЗХ>...
ЗХ>a.function(b);//но вот относится ли он к этому типу - может меняться динамически, в run-time
ЗХ>...
ЗХ>

ЗХ>Так?

Вот здесь http://www.mindview.net/WebLog/log-0025 приведен один и тот же пример как в варианте со статической типизацией, так и с динамической типизацией.

Кстати, в языках со статической типизацией так же возможно использование динамической типизации. Например, в Java, когда приходится работать с ссылками на Object (в старых контейнерах, например). Скажем, какой-то метод получает ссылку на Object, затем приводит ее к нужному типу. Компилятор здесь способен проверить только то, что после приведения ты будешь вызывать методы, которые в этом типе действительно присутствуют. Но вот возможность приведения будет отложена на этап выполнения:

class A
{
    public void function( Object untyped )
    {
        // Вот здесь работает динамическая типизация.
        B b = (B)untyped;
        // А вот здесь уже статическая.
        b.something();
    }
};

Динамически типизируемые языки позволяют отказаться от строки с приведением типа.

Здравствуйте, Зверёк Харьковский, Вы писали:

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

ЗХ>>>Господа, такой вопрос:
ЗХ>>>1. корректно ли сказать, что динамическая типизация по сравнению со статической — это замена отношения "is-a" отношением "can"?

_>>Именно так. Только динамическая еще говорит, что типы всех выражений в программе могут быть определены только на этапе выполнения.
_>>Поэтому на этапе компиляции не осуществляется проверка (или по-крайней мере не все проверки) на возможность вызова того или иного метода.

ЗХ>Во! Начинает проясняться! А как насчет людей, который опровергают это утверждение, цитируюя тебя же?

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

ЗХ>>>Это единственное отличие динамической типизации от статической?
ЗХ>>>Если да, то вопрос:
ЗХ>>>2. Если среда (компилятор, IDE) проверяет отношения can в design-time — это какая типизация — динамическая или статическая?

_>>Динамическая. С оговоркой, что только лишь если все отношения достоверно проверить нельзя.

ЗХ>Угу, я понял. Динамические типы вполне могут зависеть от введенных во время работы данных, таким образом, видя просто кусок кода типа
ЗХ>

ЗХ>a.function(b);
ЗХ>

ЗХ>далеко не всегда даже полный анализ программы в design-type покажет, какого же типа тут будет b.
ЗХ>Так?

Верно. Более того, приведу первоначальное определение ООП по Кею
1) Объект является базовой единицей системы
2) Объекты обладают состоянием
3) Объекты обмениваются сообщениями, причем каждый из них самостоятельно определяет как обработать то или иное сообщение

Т.е. написав a.function(b) ты можешь быть уверен только в том, что объекту скрывающемуся за ссылкой "a" послано сообщение "function" с параметром, скрывающимся за "b".
А что там произойдет — действие, исключение или что-либо еще, это дело того конкретного объекта.

Тут уже говорилось про #doesNotUnderstand:
Вот пример:

doesNotUnderstand: aMessage
   aMessage selector = #function:
      itTrue:
         [Transcript print: aMessage arguments first.
         ^nil].
   ^super doesNotUnderstand: aMessage

Можно завести новый класс и ввести в нем метод, описанный выше. Тогда экземпляры этого класса будут с успехом реагировать на сообщение #function: (по-умолчанию #doesNotUnderstand: бросает исключение типа MessageNotUnderstood) и печатать его аргумент на консоли.
Как видишь, таким образом объект можно наделить любым поведением, сделать динамическую поддержку любых типов в любой момент времени. Например, тот же прокси.
Таким образом, при динамической типизации типы действительно являются динамическими.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>[code]
ЗХ>...
ЗХ>a.function(b);//но вот относится ли он к этому типу — может меняться динамически, в run-time
ЗХ>...
ЗХ>[code]
Эта строчка может относиться как к динамической, так и к статической компиляции. Вообще динамическую компиляцию я проще всего понимаю на примере VB и варианта. В варианте может прийти какой угодно тип. И его проверить можно только в runtime, или вручную приведя к ожидаемому типу(VariantTypeChange).
В то же время отсутсвие типа программы не обязательно приведет к динамической типизации.

var s=0;
var s1=0.0L;

В первом случае тип int, во втором long. Есть достаточно сложные алгоритмы (чего-то там система Милнера называется) которая может рассчитать также и тип параметра в функции по вызовам.

С уважением, Gleb.

On Thu, 06 Oct 2005 09:18:44 +0400, Зверёк Харьковский""
<21481@users.rsdn.ru> wrote:

> Господа, такой вопрос:
> 1. корректно ли сказать, что динамическая типизация по сравнению со
> статической — это замена отношения "is-a" отношением "can"?
> ...

Не знаю проскакивало ли здесь такое объяснение, но оно мне нравится.
Пусть в языке имеются переменные и данные(значения).
Тогда возможны следующие вырианты языков:
1. Ни переменные ни значения не содержат характеристику типа — безтиповой
язык (ассемблер).
2. Значения имеют тип, а переменные нет — динамически типизированный язык
(erlang).
3. И значения и переменные имеют определенный тип — статически
типизированный язык (haskell).
4. Переменные имеют тип, а значения нет — такого языка я не знаю, но в
принципе и такое возможно.

--
Mikl

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

_>Здравствуйте, Mr. None, Вы писали:

_>Я возражу. По моему мнению Self настолько же строго типизирован, как и Smalltalk.

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

_>Теперь если задать вопрос, какой язык можно назвать бестиповым?
Вам превести более убедительный пример нетипизированного ОО языка (нетипизированного в том смысле, что с объектом не связано понятие типа)? Пожалуйста — Volcano. Это такой объектно ориентированный клон параллельного пролога. Я как-то раз уже приводил его в пример. Например, там объект представляется как бесконечный цикл вычисления некоторого предиката. Он даже внутреннего состояния не имеет.

_>Думаю таких языков не существует. Любой язык состоит из операций, которые работают с данными определенного типа.
Повторюсь, если речь идёт об элементарных типах данных, то да — с этой точки зрения нетипизированных языков нет. Но если типизацию рассматривать в контексте объектно ориентированной парадигмы, то нетипизированными ОО языками называют языки, в которых с объектом не связано понятие типа.