Здравствуйте, VladD2, Вы писали: VD>Тогда банальный if — это тоже полиморфизм.
Ну... в общем-то, почему бы и нет? Точнее, if может использоваться для достижения полиморфизма. Не вижу никаких препятствий этому.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Nick_, Вы писали:
VD>Ну, тогда любой код полиморфный. Ведь все значения отдельные типы. По-моему — это уже абсурд.
При чем тут любой код? Мы говорим о паттерн-матчинге.
VladD2:
> G> Применение паттерн-матчинга при задании аргументов функции — вот это является одним из самых мощных способов достижения полиморфизма в ФЯ.
> Паттерн-матчинг вообще не имеет отношения к полиморфизму. Прочитай еще раз определение из Википедии. Там четко говорится о типах.
Понятие типа "вообще" не обязательно однозначно связано с такими понятиями, выражаемыми на уровне языка, как класс, "встроенный тип", int, double и т.п.
В computer science тип в самом общем смысле берет свое начало от математического понятия разбиения на классы, и определяется как множество значений, которые может принимать переменная, константа, результат функции и т.п. Некоторые языки даже позволяют определять подтипы с явным указанием набора или диапазона принимаемых значений.
Соответстенно, в случае использования pattern matching при задании параметров функции, можно считать что для параметров определяется новый тип, значения которого задаются через использованный при определении функции pattern. Безымянный тип описывается как бы прямо в определении функции, без отдельного специального определения для типа.
Далее, о наличии полиморфизма говорят, когда один и тот же код может использоваться с разными типами (*) (**).
Таким образом, я вполне согласен с Gaperton'ом, когда он относит использование pattern matching при описании параметров функции к разновидности полиморфизма, т.к. в итоге будет выбрана соответствующая функция на основании типа аргумента (в общем смысле).
(*) В принципе, это даже не обязательно должен быть вызов функции.
(**) Бывают еще и полиморфные типы данных, но это уже другой разговор.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
> В computer science тип в самом общем смысле <...> определяется как множество значений, которые может принимать переменная, константа, результат функции и т.п.
P.S. Плюс, естественно, множество операций, к ним применимых. Хотя на приведенные рассуждения это дополнение не влияет, лучше сразу уточнить, дабы исключить лишние "разборы полетов"
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Sinclair, Вы писали:
S>Ну... в общем-то, почему бы и нет? Точнее, if может использоваться для достижения полиморфизма. Не вижу никаких препятствий этому.
Речь шала о средствах поддержки полиморфизма в языках программирования. И если начать причислять к таковым средства ветвления логики вроде if-ов, то получится "плодотвореное" обсуждение сферического коня в вакуме.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В computer science тип в самом общем смысле берет свое начало от математического понятия разбиения на классы, и определяется как множество значений, которые может принимать переменная, константа, результат функции и т.п. Некоторые языки даже позволяют определять подтипы с явным указанием набора или диапазона принимаемых значений.
ПК>Соответстенно, в случае использования pattern matching при задании параметров функции, можно считать что для параметров определяется новый тип, значения которого задаются через использованный при определении функции pattern.
Если мы не хотим получить полнейшую кашу в логике, то не нужно считать ничего что небыло заложено в самом язке. В языках поддерживающих парент-мачинг, есть четко определенное понятие типа. И парент-матчинг на это понятие не распростроняется.
Еще раз повторю, что если речь идет о средствах поддержки полиморфизма в ЯП, то нефига обсуждать средства управление ветвлением, и наче можно договориться до того, что if и switch — это тоже сресдства обеспечения полиморфизма, а вся задача программирования сводится к созданию одной полиморфной процедуры.
ПК> Безымянный тип описывается как бы прямо в определении функции, без отдельного специального определения для типа.
Ага. Безымянный тип определяется прямо в рамках if-а. Ну, ну, прада... мы же можем работать с теми же годами как с целыми. При этом любой if — начинает подразумевать ограничение на хранимую в целочисленной переменной информацию. В общем, очередной сферический конь.
ПК>Далее, о наличии полиморфизма говорят, когда один и тот же код может использоваться с разными типами (*) (**).
ПК>Таким образом, я вполне согласен с Gaperton'ом, когда он относит использование pattern matching при описании параметров функции к разновидности полиморфизма, т.к. в итоге будет выбрана соответствующая функция на основании типа аргумента (в общем смысле).
В общем, довели все до состояния сферического коня в вакуме, притянули за уши типы к значениям и на основание того что неможем отличить типов от значений зачислили if-ы и им подобные структуры в средства обеспечения полиморфизма.
Я извиняюсь, но философия должна иметь определенные приделы. Иначе можно договориться до полного маразма. Не вижу смысла отсутпать от общепринятого понятия типа данных в ЯП, а стало быть и от общепринятого понятия полиморфизма.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: VD>Речь шала о средствах поддержки полиморфизма в языках программирования. И если начать причислять к таковым средства ветвления логики вроде if-ов, то получится "плодотвореное" обсуждение сферического коня в вакуме.
Влад, не парь моск. Ничего страшного, что косвенная адресация может использоваться для обемпечения полиморфизма, причем также, как и для switch? Или уже начался вакуум? Главное отличие полиморфизма от конструкций ветвления в том, что выбор делается не явно клиентом, а средой. Ну вот паттерн-матчинг, так же как и выбор метода по типу аргумента в плюсах, делается средой.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Если мы не хотим получить полнейшую кашу в логике, то не нужно считать ничего что небыло заложено в самом язке. В языках поддерживающих парент-мачинг, есть четко определенное понятие типа. И парент-матчинг на это понятие не распростроняется.
VD>Еще раз повторю, что если речь идет о средствах поддержки полиморфизма в ЯП, то нефига обсуждать средства управление ветвлением, и наче можно договориться до того, что if и switch — это тоже сресдства обеспечения полиморфизма, а вся задача программирования сводится к созданию одной полиморфной процедуры.
VD>В общем, довели все до состояния сферического коня в вакуме, притянули за уши типы к значениям и на основание того что неможем отличить типов от значений зачислили if-ы и им подобные структуры в средства обеспечения полиморфизма.
Не все так просто. В функциональном языке трудно отличить тип от значения.
Например, что такое список? Можно рассматривать список как тип, а можно как результат функции Cons (конструктор списка).
Тогда и полиморфизм можно свести к паттерн матчингу
VladD2:
> ПК>В computer science тип в самом общем смысле берет свое начало от математического понятия разбиения на классы, и определяется как множество значений, которые может принимать переменная, константа, результат функции и т.п. Некоторые языки даже позволяют определять подтипы с явным указанием набора или диапазона принимаемых значений. > > Re[19]: Какой полиморфизм используется в ФЯ?
if здесь совершенно ни при чем, т.к. он строится так, что ему "известно" об используемых "типах" (явный выбор ветвлением), в то время как полиморфизм требует отсутствия этого знания у полиморфного кода.
Давай лучше рассмотрим несколько более близкий пример. Вот как, например, в языке Ада можно определять подтипы целого:
subtype NonNegativeInt is INTEGER range 0 .. INTEGER'LAST;
subtype NegativeInt is INTEGER range INTEGER'FIRST .. -1;
Плюс можно представить наличие двух перегруженных функций (не помню, поддерживает ли Ада перегрузку по диапазонам, но в данном случае это не важно):
procedure foo(Param: NonNegativeInt) is
begin
...
end foo;
procedure foo(Param: NegativeInteger) is
begin
...
end foo;
И вполне можно предствить себе вызовы:
foo(10);
foo(-10);
Это был бы полиморфизм?
Теперь давай перепишем то же самое без предварительного объявления типов (уже не помню, поддерживает ли такое Ада, но, снова таки, это для нас сейчас не имеет никакого значения):
procedure foo(Param: INTEGER range 0 .. INTEGER'LAST) is
begin
...
end foo;
procedure foo(Param: INTEGER range INTEGER'FIRST .. -1) is
begin
...
end foo;
Это все еще полиморфизм, или уже нет?
Я не вижу принципиальной разницы данного случая с pattern matching, разве что последнее позволяет выражать более сложные "типы" параметров по сравнению с поддиапазонами.
> ПК>Соответстенно, в случае использования pattern matching при задании параметров функции, можно считать что для параметров определяется новый тип, значения которого задаются через использованный при определении функции pattern. > > Если мы не хотим получить полнейшую кашу в логике, то не нужно считать ничего что небыло заложено в самом язке. В языках поддерживающих парент-мачинг, есть четко определенное понятие типа. И парент-матчинг на это понятие не распростроняется.
Если мы не будем "считать ничего что небыло заложено в самом язке", то мы о полиморфизме тоже говорить не будем — ибо это надъязыковое понятие.
> Я извиняюсь, но философия должна иметь определенные приделы. Иначе можно договориться до полного маразма. Не вижу смысла отсутпать от общепринятого понятия типа данных в ЯП
В таком случае дай его определение.
Подсказка: популярно-упрощенное "определение из Wikipedia:
In computer science, a datatype (often simply type) is a name or label for a set of values and some operations which can be performed on that set of values.
общепринятым в Computer Science определением не является, и не покрывает даже такой простой случай безымянного типа:
struct { int i; double m; } my_variable;
> а стало быть и от общепринятого понятия полиморфизма.
То же самое относится и к принятому Википедией "определению" полиморфизма.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Давай лучше рассмотрим несколько более близкий пример. Вот как, например, в языке Ада можно определять подтипы целого: ПК>
ПК>subtype NonNegativeInt is INTEGER range 0 .. INTEGER'LAST;
ПК>subtype NegativeInt is INTEGER range INTEGER'FIRST .. -1;
ПК>
Фишка в том, что в ФЯ нельзя определять подтипы, поэтому такое рассуждение для них не подходит. Полиморфные там только функции, паттерн-матчинг — это лишь способ декомпозиции сложных типов. Если взять и делать вид, что он выделяет некий подтип, то в рантайме мы нарвемся на ошибку non exhaustive pattern, а некоторые языки даже нервничают, если pattern неполный и пишут warnings. То, что тут писали выше (pattern matching при определении функций) это вовсе не перегрузка или что-либо еще, это syntactic sugar. Такое обявление
func pat1 = ..
func pat2 = ..
...
эквивалентно
func x = case x of
pat1 -> ..
pat2 -> ..
..
Так что в ФЯ ПМ никак не является формой полиморфизма.
Кстати, расматрение значений как типов определяемых на время вызова процедуры — это прямейшее нарушение принципов инкапсуляции. Хотя это понятие из области ООП, и слабо применимо к ФЯ, но печальные последствия при таком взгляде на жизнь не заставят себя долго ждать. Рано или поздно будут сделаны неверные предположения о "динамическом типе". На то и были придуманы приципы ООП, чтобы материализовывать все свои окраничения и предположения в рамках понтия объекта и его типа.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Влад, не парь моск. Ничего страшного, что косвенная адресация может использоваться для обемпечения полиморфизма, причем также, как и для switch? Или уже начался вакуум? Главное отличие полиморфизма от конструкций ветвления в том, что выбор делается не явно клиентом, а средой. Ну вот паттерн-матчинг, так же как и выбор метода по типу аргумента в плюсах, делается средой.
Выбор — это не полиморфизм. Полиморфизм — это отсуствие разницы в использовании объектов разного типа.
ЗЫ
А вакуум крепчал.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nick_, Вы писали:
N_>Например, что такое список? Можно рассматривать список как тип, а можно как результат функции Cons (конструктор списка).
Экземляры списков — это значения. Список позволяющий хранить элементы некоторого типа — это тип. Списко позволяющий хранить списки любого типа можно рассматривать как список хнанящий ссылки на некий базовый тип. Стало быть он тоже является одним типом, какие бы элементы в нем не находились.
N_>Тогда и полиморфизм можно свести к паттерн матчингу
N_>length Cons a b = 1 + length b N_>length x = 1
И все же это явный перебор. Перегрузка и патерн-матчинг четко разделяются и зачем их смешивать совершенно не ясно. Я собственно не спорю с тем, что патерн-матчинг — это интересное решение и красивая идея. Но с полиморфизмом ее путать не надо. Иначе так можно перемешать все понятия.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>if здесь совершенно ни при чем, т.к. он строится так, что ему "известно" об используемых "типах" (явный выбор ветвлением), в то время как полиморфизм требует отсутствия этого знания у полиморфного кода.
Гы. Патерн-матчингу тоже извесно об используемых типах. ФЯ вообще стремятся максимально много знать о типах. По этому полиморфизм в ФЯ большей частью статический. И вообще, ОО-теории хреново воспринимаются функциональщиками. Понятие инкапсуляция для ФЯ довольно пустой звук. Полиморфизм выглядит не так как в ИЯ. И вообще мировозрение сильно иное. Основная тенденция — это замена инкапсуляции на декомпозицию. Т.е. вместо абстрагингвании данных упор делается на абстрагировании кода. Корче другой мир.
ПК>Давай лучше рассмотрим несколько более близкий пример. Вот как, например, в языке Ада можно определять подтипы целого: ПК>
ПК>subtype NonNegativeInt is INTEGER range 0 .. INTEGER'LAST;
ПК>subtype NegativeInt is INTEGER range INTEGER'FIRST .. -1;
ПК>
ПК>Плюс можно представить наличие двух перегруженных функций (не помню, поддерживает ли Ада перегрузку по диапазонам, но в данном случае это не важно):... ПК>Это был бы полиморфизм?
Гы. Это полиморфизм. Так как есть разные четко различимыетипы и способность намерянно скрывать разницу между ними. А вот если типы не вводить, а делать проверки при определении функций или при их вызове, то это уже управление ветвлением.
В твоем примере даже не нужно вводить диапазонов. Это по сути не важно. Достаточно чтобы типы просто по разному интерпретировались. Скажем, типы скорость и масса могут измеряться целыми числами лежащими в одном диапазоне. Но интерпретироваться они будут по разному. Так что в терминах АДА-ы можно было бы написать нечто вроде:
subtype velocity is INTEGER;
subtype mass is INTEGER;
...
procedure foo(Param: velocity) is
begin
...
end foo;
procedure foo(Param: mass) is
begin
...
end foo;
...
ну, и потом создать две переменные, присвоить им одинаковые (с точки зрения целых чисел) значения и вызвать метод foo. При этом должен вызваться нужный перегруженный метод. Я не случаяно тут упомянул слово метод, так как это чистейшей воды ООП, хотя и в несколько процедурной форме.
Другими словами неважно, что типы принадлежать к разным диапазонам значений. Важно, что они обрабатываются как разные типы.
А вот когда одинаковые типы обрабатываются в звисимости от их значений, то это всего лишь вид ветвления исполнения. И совершенно пофигу как оно реализовано. Паттерн-матчинг позволяет перенести выбор из описания вызова функции в описание самой функции. Это несомненно интересное решение и оно точно так же как и перегрузка функций позволяет сделать код менее комплексным и более наглядным, но это не полиморфизм! Увы.
ПК>Теперь давай перепишем то же самое без предварительного объявления типов (уже не помню, поддерживает ли такое Ада,
Не уверен, но вроде нет. Ада врде как тяготеет к строгости, и типы имеющие разные названия в ней интерпретируются как разные. Так что типы с одинаковыми ограничениями просто не совпадут. Так что динамическое их определение бессмысленно. Собственно это и есть разница между патерн-матчингом (динамической проверкой значения) и полиморфизмом (пофигу какой проверки типов).
ПК> но, снова таки, это для нас сейчас не имеет никакого значения): ПК>
ПК> procedure foo(Param: INTEGER range 0 .. INTEGER'LAST) is
ПК> begin
ПК> ...
ПК> end foo;
ПК> procedure foo(Param: INTEGER range INTEGER'FIRST .. -1) is
ПК> begin
ПК> ...
ПК> end foo;
ПК>
ПК>Это все еще полиморфизм, или уже нет?
По-моему — это глупость. Объяви методы вот так:
procedure foo(Param: INTEGER range 0 .. 5) is
...
procedure foo(Param: INTEGER range INTEGER 4 .. 10) is
...
И подсунь им в качестве значения 4 или 5. Что при этом произойдет? А вот при объявленом типе все будет четко не взирая на значение переменных. Это и есть разница между полиморфизмом и паттерн-матчингом.
Языки поддерживающие паттерн-матчинг обычно проверяют, чтобы условия диапазона значений не пересикались. Ну, или выбирают первый подходящий диапазон. Делается это примерно по такой схеме:
def foo(int val) =
where
if паттерн1: {...}
else if паттерн2: {...}
else : {...}
Собственно это легко переписывается в импиративном стиле
int foo(int val)
{
if (паттерн1(val))
foo1(val);
else if (паттерн2(val))
foo2(val);
else
foo3(val);
}
ПК>Я не вижу принципиальной разницы данного случая с pattern matching, разве что последнее позволяет выражать более сложные "типы" параметров по сравнению с поддиапазонами.
Ну, может теперь увидишь.
ПК>Если мы не будем "считать ничего что небыло заложено в самом язке", то мы о полиморфизме тоже говорить не будем — ибо это надъязыковое понятие.
Нет уж. Полиморфизм поддерживается языком. В ООП — это обычно перегрузка методов и переопределение методов. В приципе еще есть еще мультиметоды (перегрузка более чем по одному типу). И все это не паттерн-матчинг. Так как паттерн-матчинг анализирует значения не обращая внимание на тип аргумента.
ПК>В таком случае дай его определение.
Уже задолбался это делать. Я тут уже раз 10 давал ссылки на Википедию. Поиск тебе поможет.
ПК>Подсказка: популярно-упрощенное "определение из Wikipedia: ПК>
In computer science, a datatype (often simply type) is a name or label for a set of values and some operations which can be performed on that set of values.
ПК>общепринятым в Computer Science определением не является,
Чушь.
ПК> и не покрывает даже такой простой случай безымянного типа: ПК>
ПК>struct { int i; double m; } my_variable;
ПК>
И правильно делает. Потому-что это нарушение теории типов. Безымянные типы подразумевают сличение типов по соотвествию физической структуры типа данных. А это в свою очередь, является грубейшим нарушением инкапсуляции и левейшим хаком. К сожалению, подобные хаки включены во многие ЯП, что не делает чести их разработчикам.
Ты описал тип у которого потиряли имя. По идее нормальный компилятор/интерпритатор просто не должен знать что с ним делать дальше, так как он не имеет права дать привести этот тип к некоторому известному, ну, а без этого такое обявление ничем не отличается от объявления двух отдельных переменных (m и i).
>> а стало быть и от общепринятого понятия полиморфизма.
ПК>То же самое относится и к принятому Википедией "определению" полиморфизма.
В Википедии дано нормальное понятие типа. Можешь попытаться найти другое. И попытаться впихнуть в него динамические проверки значений. Но боюсь тебя ждет большой облом.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2:
> ПК> if здесь совершенно ни при чем, т.к. он строится так, что ему "известно" об используемых "типах" (явный выбор ветвлением), в то время как полиморфизм требует отсутствия этого знания у полиморфного кода.
> Гы. Патерн-матчингу тоже извесно об используемых типах.
Главное, что об этом не было бы известно в точке использования определенных таким образом функций. В случае pattern matching в параметрах это так, в случае if это не так. Наличие явных определений всех функций просто означает, что это форма ближе к ad-hoc полиморфизму, наравне с перегрузкой, а не к параметрическому полиморфизму, как это имеет место, когда одна и та же функция может работать с данными разных типов.
> И вообще, ОО-теории хреново воспринимаются функциональщиками.
Полиморфизм не требует ООП. Более того, понятие полиморфизма "родилось" именно в одном из функциональных языков, в ML, в 1976 г. Так что ОО в данном случае — переход на другую тему.
> ПК>Давай лучше рассмотрим несколько более близкий пример. Вот как, например, в языке Ада можно определять подтипы целого: > ПК>
> ПК>subtype NonNegativeInt is INTEGER range 0 .. INTEGER'LAST;
> ПК>subtype NegativeInt is INTEGER range INTEGER'FIRST .. -1;
> ПК>
> ПК>Плюс можно представить наличие двух перегруженных функций (не помню, поддерживает ли Ада перегрузку по диапазонам, но в данном случае это не важно):... > ПК>Это был бы полиморфизм? > > Гы. Это полиморфизм. Так как есть разные четко различимыетипы и способность намерянно скрывать разницу между ними. А вот если типы не вводить, а делать проверки при определении функций или при их вызове, то это уже управление ветвлением. <...>
Все зависит от системы типов, принятой в языке. Теории типов/языков программирования допускают различные системы типов, не запрещая и определение типа по значению. Для этого даже термин специальный есть type inference. В одной из форм присутствует и во многих функциональных языках.
> ПК>Теперь давай перепишем то же самое без предварительного объявления типов (уже не помню, поддерживает ли такое Ада,
> <...> динамическое их определение бессмысленно. Собственно это и есть разница между патерн-матчингом (динамической проверкой значения) и полиморфизмом (пофигу какой проверки типов).
В Аде переменным подтипов, введенных как диапазон "базового" типа, можно присваивать значения как других диапазонов той же "базы", так и "базового" типа. Все проверки выполняются именно во время исполнения. Соответственно, если бы в Аде можно было бы подобным образом перегрузить функции для поддиапазонов, то выбор функции производился бы именно во время их вызова, т.к. можно было бы написать именно так:
foo(10);
foo(-1);
без явного указания, к какому диапазону относится значение.
> Объяви методы вот так: >
> procedure foo(Param: INTEGER range 0 .. 5) is
> ...
> procedure foo(Param: INTEGER range INTEGER 4 .. 10) is
> ...
>
> И подсунь им в качестве значения 4 или 5. Что при этом произойдет?
Ошибка времени исполнения. Или какой-нибудь компромисс в виде выбора первого подошедшего варианта (не в стиле Ады). Или ошибка компиляции из-за того, что диапазоны пересекаются, если бы такое определение не было бы разрешено. Суть проектное решение автора языка. Для наших рассуждений, какой выбор он сделает, погоды не играет.
> ПК>Подсказка: популярно-упрощенное "определение из Wikipedia: > ПК>
In computer science, a datatype (often simply type) is a name or label for a set of values and some operations which can be performed on that set of values.
> ПК>общепринятым в Computer Science определением не является, > > Чушь.
Не чушь, а факт жизни. Подними любую специализированную статью или книгу по теории типов или языков программирования.
> ПК> и не покрывает даже такой простой случай безымянного типа: > ПК>
> ПК>struct { int i; double m; } my_variable;
> ПК>
> > И правильно делает. Потому-что это нарушение теории типов.
Теория типов различает две системы определения совместимости типов: структурную и именную. Обе имеют право на жизнь, хотя именная традиционно (и справедливо) считается более безопасной.
> Безымянные типы подразумевают сличение типов по соотвествию физической структуры типа данных.
Именные тоже так могут сравниваться. Все зависит от того, какая система типов принята в том или ином языке.
> В Википедии дано нормальное понятие типа. Можешь попытаться найти другое. И попытаться впихнуть в него динамические проверки значений. Но боюсь тебя ждет большой облом.
In computer science, a datatype (often simply called type) is a statically assigned constraint on a programming language phrase that denotes the kinds of values it may take on and gives it certain semantic meaning for the purposes of preventing errors, building abstractions, documenting the program, and gaining some measure of runtime safety and efficiency.
Динамические проверки значений даже впихивать не нужно: это называется динамическая типизация, и известно давным-давно.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Тогда уж скорее статической типизации...
Похоже ты все же начинашь понимать... Хотя еще не доконца.
ПК> Каким образом динамическое определение типа нарушает инкапсуляцию?
Динамического определения типов по большому счету небывает. Его конечно можно отложить во времени, но после определения ты получишь субстанцию ни чем не отличающуюся от статически определенной. Можно даже использовать в разное время одно и тоже имя для определения типа. Но это всего лишь некрасивая возможность на подобии переопределения переменной.
Даже в языках с динамической типизацией понятие тип не исчезает. Так что проблем быть не должно.
Гипотетический пример:
class A is 1..10
class B is 3..120
def A.Test:
print "A:" + self
def B.Test:
print "B:" + self
var1 = A.new(5) // переменная на время получает значение типа А (нинамическая типизация в действии)
var1.Test() // Вызов A.Test
var1 = B.new(5) // Переменная переопределяется и начинает указывать на объект другого типа.
var1.Test() // Вызов B.Test
В общем, суть понятия типа от динамического характера языка не меняется. Задание типа на одни вызов является полнейшей профанацией. А изменение типа объекта в рантайме (не путать с изменением типа переменной или с вариантными типами) просто сумашедшей идеей ломающей все концепции ООП (полиморфизм, инкапсуляцию), и я бы даже сказал, уничтожающую понятие типа как такового.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Главное, что об этом не было бы известно в точке использования определенных таким образом функций. В случае pattern matching в параметрах это так, в случае if это не так. Наличие явных определений всех функций просто означает, что это форма ближе к ad-hoc полиморфизму, наравне с перегрузкой, а не к параметрическому полиморфизму, как это имеет место, когда одна и та же функция может работать с данными разных типов.
Извини, но это чушь. Эдакий полиморфизм можно сделать зи ифа написав один макрос.
>> И вообще, ОО-теории хреново воспринимаются функциональщиками.
ПК>Полиморфизм не требует ООП. Более того, понятие полиморфизма "родилось" именно в одном из функциональных языков, в ML, в 1976 г. Так что ОО в данном случае — переход на другую тему.
А я и не утрверждал, что с полиморфизмом в ФЯ есть какие-то проблемы. Пробелмы имеются с инкапсуляцией и вообще с восприятием ООП как идиомы.
>> Гы. Это полиморфизм. Так как есть разные четко различимыетипы и способность намерянно скрывать разницу между ними. А вот если типы не вводить, а делать проверки при определении функций или при их вызове, то это уже управление ветвлением. <...>
ПК>Все зависит от системы типов, принятой в языке. Теории типов/языков программирования допускают различные системы типов, не запрещая и определение типа по значению. Для этого даже термин специальный есть type inference. В одной из форм присутствует и во многих функциональных языках.
Нет никаких типов по значению. Есть типы и есть экземляры этих типов. Значения могут быть только в экземплярах. Иначе это уже вакханалия. Тип затем и был придуман, чтобы работать с ним как с доменом, а не как с набором значений. Большинство языки о которых идет речь реализуют совершенно обыкновенную систему типов. Тот же Окамл даже классы поддерживает. В них есть понятие перегрузки. И оно четко отделяется от понятия паттерн-матчинга. Так что не нужно снова заводить эту песню. Думаю, что ты и сам уже на своих примерах понял, что был не прав.
ПК>В Аде переменным подтипов, введенных как диапазон "базового" типа, можно присваивать значения как других диапазонов той же "базы", так и "базового" типа.
Т.е. автоматическое приведение? Тогда это вообще работать не будет. Будет невозможна ни перегрузка, ни паттерн-матчинг.
ПК> Все проверки выполняются именно во время исполнения. Соответственно, если бы в Аде можно было бы подобным образом перегрузить функции для поддиапазонов, то выбор функции производился бы именно во время их вызова, т.к. можно было бы написать именно так:
Извини, но говорить о гипотетической глупости на базе совершенно мне незнакомого языка я не хочу. Мне кажется я уже довольно хорошо донес свою мысль. Я исхожу из классического определения типов, полиморфизма и т.п. Так что в разговорах со мной лучше избегать терминов из области управления сферическми конями в вакууме.
ПК>Ошибка времени исполнения.
не в стиле Ады
(с) ты.
ПК> Или какой-нибудь компромисс в виде выбора первого подошедшего варианта (не в стиле Ады).
Во-во.
ПК> Или ошибка компиляции из-за того, что диапазоны пересекаются, если бы такое определение не было бы разрешено. Суть проектное решение автора языка. Для наших рассуждений, какой выбор он сделает, погоды не играет.
Или другое гадание на кофейной гуще. Предлагаю завязать. Навязывать мне столь необоснованную точку зрения действительно бессмысленно.
Пока что я придерживаюсь мнения о том, что полиморфизм — это работа с объектами разных типов одинаковыми метадами. А паттерн-матчикнг — это работа со с разными значениями одного типа одинаковыми метадами. Если будут аргументы отличные от кармического понимания сущьности тип, то с удовольствием продолжу обсуждение. А так надоело.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2:
> ПК> Каким образом динамическое определение типа нарушает инкапсуляцию?
> Динамического определения типов по большому счету небывает.
Бывает, но это уже другой разговор.
В этом разговоре речь шла не об определении самих типов, структура которых, в данном случае, определяется на этапе написания программы, а об определении совместимости типов во время вызова функции. При этом совместимость, очевидно, проверяется по структуре типа, а не по его имени, которого у него нет.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
