Снова о типизации :)
От: Зверёк Харьковский  
Дата: 06.10.05 05:18
Оценка:
Господа, такой вопрос:
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 — это какая типизация — динамическая или статическая?
FAQ — це мiй ай-кью!
Re: Снова о типизации :)
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 06.10.05 05:41
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Господа, такой вопрос:

ЗХ>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.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re: Снова о типизации :)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 06.10.05 07:43
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

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


Может лучше "like-a" ?
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Снова о типизации :)
От: Зверёк Харьковский  
Дата: 06.10.05 10:31
Оценка:
Здравствуйте, eao197, Вы писали:

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


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


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

А как насчет ответа на второй вопрос?
FAQ — це мiй ай-кью!
Re: Снова о типизации :)
От: GlebZ Россия  
Дата: 06.10.05 10:40
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:


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

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

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

(с)_vovin здесь
Автор: _vovin
Дата: 04.03.05


С уважением, Gleb.
Re[2]: Снова о типизации :)
От: _vovin http://www.pragmatic-architect.com
Дата: 06.10.05 10:56
Оценка: 2 (2)
Здравствуйте, 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 программы создаются не как набор исходных текстов с дальнейшей их трансляцией, а посредством манипулирования объектами-классами с прозрачным внесением изменений во все созданные объекты-экземпляры].

Теперь если задать вопрос, какой язык можно назвать бестиповым?
Думаю таких языков не существует. Любой язык состоит из операций, которые работают с данными определенного типа.
Тот же ассемблер, где типы различаются по размерности, знаковости, целое/плавающее число и т.д.
А вот то, что любые данные могут быть интерпретированы как данные другого типа — это в точности слабая типизация.
Другой пример слабой типизации — сложение строк с числами, использование строк как числовых значений (например как индекс в массиве), и т.д.
Re[2]: Снова о типизации :)
От: Dyoma Россия http://www.livejournal.com/users/dyomap/
Дата: 06.10.05 11:01
Оценка:
Здравствуйте, Mr. None, Вы писали:

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


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

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

Dyoma
ALMWorks
http://deskzilla.com/
Re[3]: Снова о типизации :)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 06.10.05 11:18
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>>>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 остается интерпритируемым динамическим языком.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Снова о типизации :)
От: _vovin http://www.pragmatic-architect.com
Дата: 06.10.05 11:24
Оценка: 45 (2)
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Господа, такой вопрос:

ЗХ>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 — это какая типизация — динамическая или статическая?

Динамическая. С оговоркой, что только лишь если все отношения достоверно проверить нельзя.
Re[2]: Снова о типизации :)
От: Зверёк Харьковский  
Дата: 06.10.05 11:26
Оценка:
Здравствуйте, 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]

Так?
FAQ — це мiй ай-кью!
Re[3]: Снова о типизации :)
От: _vovin http://www.pragmatic-architect.com
Дата: 06.10.05 11:28
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

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

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

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


ЗХ>Так?


Это пример какой типизации?
Re[2]: Снова о типизации :)
От: Зверёк Харьковский  
Дата: 06.10.05 11:32
Оценка:
Здравствуйте, _vovin, Вы писали:

ЗХ>>Господа, такой вопрос:

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

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

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

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

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

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

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


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

далеко не всегда даже полный анализ программы в design-type покажет, какого же типа тут будет b.
Так?
FAQ — це мiй ай-кью!
Re[3]: Снова о типизации :)
От: Gaperton http://gaperton.livejournal.com
Дата: 06.10.05 11:36
Оценка: 1 (1) +1
Здравствуйте, _vovin, Вы писали:

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

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

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

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

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

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

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

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

+1
Re[4]: Снова о типизации :)
От: Зверёк Харьковский  
Дата: 06.10.05 11:36
Оценка:
Здравствуйте, _vovin, Вы писали:

ЗХ>>Так?


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

Да я уже сам перестал понимать...
FAQ — це мiй ай-кью!
Re[4]: Снова о типизации :)
От: _vovin http://www.pragmatic-architect.com
Дата: 06.10.05 11:42
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


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


Подписываюсь под каждым словом.
Re[3]: Снова о типизации :)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 06.10.05 11:54
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

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

ЗХ>
ЗХ>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();
    }
};

Динамически типизируемые языки позволяют отказаться от строки с приведением типа.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Снова о типизации :)
От: _vovin http://www.pragmatic-architect.com
Дата: 06.10.05 11:55
Оценка: 17 (1)
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Здравствуйте, _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) и печатать его аргумент на консоли.
Как видишь, таким образом объект можно наделить любым поведением, сделать динамическую поддержку любых типов в любой момент времени. Например, тот же прокси.
Таким образом, при динамической типизации типы действительно являются динамическими.
Re[3]: Снова о типизации :)
От: GlebZ Россия  
Дата: 06.10.05 12:00
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>[code]

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

var s=0;
var s1=0.0L;

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

С уважением, Gleb.
Re: Снова о типизации :)
От: Mikl Kurkov Россия  
Дата: 06.10.05 14:35
Оценка: 1 (1)
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
Posted via RSDN NNTP Server 1.9
Re[3]: Снова о типизации :)
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 07.10.05 03:15
Оценка:
Здравствуйте, _vovin, Вы писали:

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


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


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

_>Теперь если задать вопрос, какой язык можно назвать бестиповым?

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

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

Повторюсь, если речь идёт об элементарных типах данных, то да — с этой точки зрения нетипизированных языков нет. Но если типизацию рассматривать в контексте объектно ориентированной парадигмы, то нетипизированными ОО языками называют языки, в которых с объектом не связано понятие типа.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[2]: Снова о типизации :)
От: Gaperton http://gaperton.livejournal.com
Дата: 07.10.05 12:07
Оценка: +1
Здравствуйте, Mikl Kurkov, Вы писали:

MK>4. Переменные имеют тип, а значения нет — такого языка я не знаю, но в

MK>принципе и такое возможно.
Ну как же. Это же C. Слабая статическая типизация.
Re[4]: Снова о типизации :)
От: Зверёк Харьковский  
Дата: 07.10.05 15:12
Оценка:
Здравствуйте, _vovin, Вы писали:

_>Верно. Более того, приведу первоначальное определение ООП по Кею

_>1) Объект является базовой единицей системы
_>2) Объекты обладают состоянием
_>3) Объекты обмениваются сообщениями, причем каждый из них самостоятельно определяет как обработать то или иное сообщение

Т.е. с точки зрения "радикального ООП" понятие "класса" — это не более чем способ сгруппировать несколько поведений. Не фундаментальная концепция, а просто "синтаксический сахар". Ы?

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


Тут, на мой вкус, есть один интересный момент. Лично мне удобней думать в терминологии "a и b вступили в отношение function" (чего Смоллтолк, к примеру, не позволяет). Разница в том, что допустимость и результат этих отношений может определяться как объектом a, так и объектом b (а равно и обоими вместе).

//Скажем, в C++, видя запись
a+b
//мы можем ожидать, что определен либо
a.operator+(b);
//либо 
operator+(a,b);

//а в D, к слову, может быть
a.opAdd(b)
//или
b.opAdd_r(a)


Мне кажется, такое представление в каких-то случаях более естественно. Хотя, в том же C++ такая штука проходит только с операторами:
//вот в этом случае:
a.function(b);
//обязательно наличие именно (1)
a.function(b);
//но не (2)
function(a,b);
//и не (3)
b.function_r(a);


Интересно, что Павел Кузнецов, помнится, что-то говорил о возможности введения (2) в стандарт
FAQ — це мiй ай-кью!
Re[2]: Снова о типизации :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.05 19:35
Оценка:
Здравствуйте, Mikl Kurkov, Вы писали:

MK>Тогда возможны следующие вырианты языков:

MK>1. Ни переменные ни значения не содержат характеристику типа — безтиповой
MK>язык (ассемблер).

Вобще-то ассемблеры имеют хотя и смутную, но типизацию. Так операторы имеют понятие о типе.

5. Присуствует и динамическая, и статическая типизация. Примеров тому масса. Тот же C# и VB.

6. Присуствует слабая типизация, т.е. когда вроде как она есть, но ее можно легко нарушить. Примеры: С, С++ и целая туча языков. Пожалуй самый распространенный случай на сегодня.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Снова о типизации :)
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 14.11.05 07:20
Оценка:
Здравствуйте, VladD2, Вы писали:
MK>>1. Ни переменные ни значения не содержат характеристику типа — безтиповой
MK>>язык (ассемблер).

VD>Вобще-то ассемблеры имеют хотя и смутную, но типизацию. Так операторы имеют понятие о типе.


Имхо, это и есть определение безтиповости, когда тип значения, определяется применённым оператором, а не содержиммым значения.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[5]: Снова о типизации :)
От: Voblin Россия http://maslyaew.narod.ru/
Дата: 14.11.05 17:16
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Тут, на мой вкус, есть один интересный момент. Лично мне удобней думать в терминологии "a и b вступили в отношение function" (чего Смоллтолк, к примеру, не позволяет). Разница в том, что допустимость и результат этих отношений может определяться как объектом a, так и объектом b (а равно и обоими вместе).


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

Пример обработки "на равных" — это тот самый оператор +. Можно сколь угодно упражняться в перректальных методиках, но следующие действия:
c = a+b;

c = a.operator+(b);

c = b.operator+(a);

означают только то, что значения, содержащиеся в переменных a и b дружно отправятся на сумматор (та самая третья сторона!), и затем запишутся в переменную c. Если, конечно, это числа.

Что характерно, с точки зрения объектов a и b, вычисление их суммы — бессмысленное занятие, так как оно не меняет их состояния. И вообще, целое число не обязано уметь суммироваться. Оно просто должно уметь качественно отдать 32 двоичных разряда.

В данном случае единственный, кто "заинтересован" в вычислении суммы, это объект c. Поэтому вышеприведённый маразм можно довести до абсурда следующим образом:
c.ClacSumAndAssign(a, b); // Чур меня, чур...

Шутки шутками, но ведь очень часто возникают ситуации, когда не понятно, кто должен делать действие. Например, если делать на объектах геометрическую считалку, то вполне может возникнуть потребность научиться находить точки пересечения фигур. Вернее, множества геом. фигур пересечения (они ведь могут пересекаться неоднократно, и не обязательно в точках). Засучив рукава, реализуем все возможные варианты:
CFigureArr* CSegment::GetIntersections(CSegment &other); // отрезок с отрезком
CFigureArr* CLine::GetIntersections(CSegment &other); // прямая с отрезком
CFigureArr* CCircle::GetIntersections(CSegment &other);
CFigureArr* CEllipse::GetIntersections(CSegment &other);
CFigureArr* CPolyLine::GetIntersections(CSegment &other);
CFigureArr* CBezier::GetIntersections(CSegment &other);
CFigureArr* CArc::GetIntersections(CSegment &other);
CFigureArr* CPoint::GetIntersections(CSegment &other); // Так, для комплекта
// а теперь весело, с улыбочкой, всё то же самое с прямой
CFigureArr* CSegment::GetIntersections(CLine &other);
CFigureArr* CLine::GetIntersections(CLine &other);
// ................. и т.д.

А потом, в случае добавления какой-нибудь хитрой штуки типа CSquare, схватиться за голову и, мало того, что нарисовать все методы у CSquare, но и испоганить уже отлаженный и работающие CSegment, CLine и т.д.

Предложения халявщиков о том, что реализовать CSegment::GetIntersections(CLine &other) можно через вызов CLine::GetIntersections(CSegment &other) следует гневно отвергнуть, так как оставить такую гнусненькую неочевидную зависимость объектов между собой... ну вы меня поняли, это очень неаккуратно.

Как видим, гораздо разумнее всё это хозяйство замутить в одном месте. И, может быть, удобнее всего это сделать в CFigureArr. Или вообще обойтись без отдельного класса, а изготовить вульгарную функцию.

А всё почему?
Да потому, что пересечение (являющееся множеством геометрических фигур) — это свойство множества геометрических фигур. Пересечение с конкретной окружностью не является свойством конкретного отрезка. Пересечение — это свойство этой неупорядоченной (!!!) пары экземпляров.

Так что, господа, равноправные "отношения" — та ещё песня. И не надо реализовывать их...
ЗХ>...как объектом a, так и объектом b (а равно и обоими вместе).
Re[4]: Снова о типизации :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.11.05 22:58
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Имхо, это и есть определение безтиповости, когда тип значения, определяется применённым оператором, а не содержиммым значения.


И все же понятие типа присуствует. Так что на 100% от него даже тут не уйти.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.