Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Курилка, Вы писали:
К>>Ммм, я в Скале не до конца разбираюсь,
E>Я, кстати, то же. Поскольку не выдержал штудирования ScalaReference где-то на половине. E>Может быть, будь по Скале какое-нибудь фундаментальное введение в язык, вроде Programming Ruby 2nd Дейва Томаса или хотя бы "Язык программирования C++" Страуструпа, все было бы и не так страшно. Но изучать язык по его спецификации, написанной на сухом математическом языке -- можно застрелиться. Ко- и контра- вариантности я еще как-то понимал. Но когда в дело еще начала вмешиваться линеаризация классов/примесей (причем выполняющаяся справа на лево), да добавились view я просто сдался
Да, есть такой момент, популяризация — вещь очень важная для продвижения технологий/методик и т.п.
К>> но разве тут не будут использоваться неявные преобразования? Чтобы получить из T U или наоборот?
E>Они будут использоваться только, если в прототипе min указать, что какой-то и параметров может быть выведен неявно. Но, если кто-то зафиксировал min в простом варианте, без implicit спецификаций, то ничего уже не сделать. AFAIK.
Да точно, как раз недавно читал про implicit. Но разве не логично сигнатуру библиотечной функции выбирать подумав предварительно, что как и где будет использоваться?
Re[11]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, Курилка, Вы писали:
E>>Они будут использоваться только, если в прототипе min указать, что какой-то и параметров может быть выведен неявно. Но, если кто-то зафиксировал min в простом варианте, без implicit спецификаций, то ничего уже не сделать. AFAIK.
К>Да точно, как раз недавно читал про implicit. Но разве не логично сигнатуру библиотечной функции выбирать подумав предварительно, что как и где будет использоваться?
По моему скромному опыту, это практически невозможно -- сразу предугадать как будет использоваться функция. Полезные вещи, как правило, начинают применяться даже такими способами, какие автору этой вещи и не снились изначально
И возвращаясь к утиной типизации -- посмотри на мой пример на Ruby -- там ведь вообще не нужно заботится о неявных преобразованиях одного к другому. Утиная типизация в чистом виде -- пока коду хватает методов объекта нет надобности в том, чтобы из SimpleFraction делали BcdNumber или наоборот.
Тем более, что вот еще странность. Ведь в принципе, эти фрагменты 1) и 2) должны быть эквиваленты:
def doSomething[t]( v: t ) { ... }
val b : BcdNumber = ...
val s : SimpleFraction = ...
// 1)
doSomething( min( b, s ) );
// 2)
if( b < s )
doSomething( b )
else
doSomething( s )
всего лишь вызов doSomething для объекта с минимальным значением. Но!
Если есть неявное преобразование из SimpleFraction в BcdNumber которое будет использоваться при обращении к min, то doSomething всегда в случае 1) будет вызываться с объектом BcdNumber.
Но, если в BcdNumber есть оператор < для SimpleFaction, то в случае 2) компилятор сгенерирует два обращения к doSomething но с разными типами аргументов!
Вот такие курьезы.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, eao197, Вы писали:
E>Если есть неявное преобразование из SimpleFraction в BcdNumber которое будет использоваться при обращении к min, то doSomething всегда в случае 1) будет вызываться с объектом BcdNumber. E>Но, если в BcdNumber есть оператор < для SimpleFaction, то в случае 2) компилятор сгенерирует два обращения к doSomething но с разными типами аргументов!
E>Вот такие курьезы.
Просто тут получается, что 2 разных пути неявных преобразований — один в min, другой в <
Из-за этого и получаем путаницу.
Имхо тут было бы логичней оставить один, а именно который в операторе сравниения.
Хотя как практически это реализовать пока не могу додумать.
Правда путаница какая-то получается
Re[12]: Как скрестить ужа и ежа или статическую и утиные тип
E>По моему скромному опыту, это практически невозможно -- сразу предугадать как будет использоваться функция. Полезные вещи, как правило, начинают применяться даже такими способами, какие автору этой вещи и не снились изначально
Угу. Признак хорошей либы — если она используется так, как не мог предположить разработчик.
Здравствуйте, FR, Вы писали:
FR>Ну питон традиционно оттуда разные вещи утягивает
Вот только непоследовательно. Надо было начинать с паттерн-матчинга и алгеброических типов.
FR>Ты статью внимательнее почитай, там есть про мотивировку и там нет цели выводить все во время компиляции.
Прочитал. Когда дочитал до конца возник резонный вопрос. Ну, ты знаешь какой. Такое ощущение, что товарищь блуждая по Интернету набрел то ли на Немерле, то ли на Скалу. Синтаксис во многом 1 в 1 содран.
А вообще, товарищь правильным путем свои мысли развивает. Медленно, правда.
Мне вот интересно, что ты вдруг вспомнил о статьях двух-годичной давности?
И еще интересно, что ты после этого скажешь о старой доброй теме статика вс. динамика, если даже создатель твоего любимого языка явно плывет по течению к статической типизации и выводу типов? Отстаешь ты явно от своих кумиров.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, AndreiF, Вы писали:
AF>Тема недостатков статической типизации не раскрыта.
Скажу больше. В обоих статьях я заметил исключительно сожаления о том, что Питон не имеет возможности статически типизировать код и идеи о том, как прикрутить статическую типизацию к Питону.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, FR, Вы писали:
FR>Так вроде все на поверхности, но недостатки не вообще статической типизации а схемы "тип == класс" которая ограничена и менее общая чем схема "тип по сигнатуре", по второй схеме обобщенные функции вводятся легко и естественно. Ну и кроме того обозначены и некторые проблемы которые например в том же окамле (а он типизирован по второй схеме) не разрешены.
Мне кажется, что ты хочешь видеть то, чего нет в этих статьях и не хочешь то, что там есть.
Ни одного слова про недостатки статической типизации там не сказано. Там просто рассуждается о том, что схема Хаскеля (Хаскель, правда не называется, но это именно его схема) отлично подходит для введения статической типизации в ранее полностью динамический язык вроде Питона.
Про ОКамл ты тоже что-то путаешь. Привди, плиз цитаты.
Про вывод обобщенных типов тоже. Он как раз предлагает задавать сигнатуры обобщенных типов явно. Что 1 в 1 копирует дотнетуно-явовскую схему. И вообще интерфейсы описанные товарищем 1 в 1 явновские/дотнетные. Даже ограничения и те скопированы (вплодь до ключевого слва where). Тоько принцип их применения скорее похож на развитие идей классов типов Хаскеля. В прочем классы типов Хаскеля тоже имеют очень много общего с интерфейсами дотнета/явы. Так что все логично.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, AndreiF, Вы писали:
AF>Насколько я помню, такая техника называется interface inference и уже применяется в других языках. Со схемой "тип=класс" она никак не конфликтует, на самом деле, и их можно благополучно применять одновременно.
Скажу больше — это вообще терминалогическая эквилибристика.
То что товарищь называет классом в Хаскеле называется воплощением (instatnce) и классом в дотнете/яве. То что он называет интерфейсом называется классом типа в Хаскеле и интерфейсом в дотнете/яве. А то что он называет типом называется "наиболее общий тип" и не имеет аналога в дотнете/яве, так как они не выводят типы. Но подобная фигня есть в Немерле, хотя она опять же имени не имеет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, FR, Вы писали:
FR>Ну у ван Россумма интерфейс понятие более широкое чем в Шарпе, он хочет под интерфейс подвести не только сигнатуру но и контракт.
Я вот прочел статью и понял, что просто у тебя каша. У твоего ван Россумма как раз интерфейс 1 в 1 явовский (шарп ковариантности не пдоупскает, а так бы был и шарповским). Разница только в применении. Это твой ван Россумма предлагает ассоциировать интерфейсы с конкретными объектами динамически (ну, или с конкретными классам статически, но неявно, а по утиному). Собственно в этом есть рациональное зерно, так как в системе типов дотнеа и явы есть дна засада. Нельзя без создания адаптера ассоциировать интерфейс с уже имеющимся (в бинарном виде, например) классом. В Хаскеле и мечтах ван Россумма это возомжно. В этом заключается приемущество. Недостаток же заключается в том, что такая ассоциация во-первых может получиться случаяно (с вытекающей из этого семантической ошибкой), а во-вторых не гибка (надо совпадение сигнатур методов, а этого может не быть). В Хаскеле это сделано более элегантно. Этот язык заставляет объявлять ассоциазции типов и интерфейсов (классов типов в его терминалогии) явно. Это с одно стороны оставляет полный контроль, а с другой дает большую гибкость нежели в явопдобных системах типов. Однако это плохо вяжется с динамикой в стиле Питона. Но тут уж надо быть последовательным. Рассуждения ван Россумма явно говорят о том, что он склоняется к отказу от динамики в пользу вывода типов с частичной их аннотацией (1 в 1 идея раелизованаая в Немерле). Вот только тут все зависит от того насколько он будет последователен в своих размышлениях и действиях. Если будет последователен, то через несклько лет Питон превратится в нечто очень похожее на Немерле . Если нет, будет еще тот езжоужжик который скорее соберет все худшее из двух миров.
VD>>А разница должна заключаться тольк в том, что сопоставление кокретного объекта и этого интерфейса/класса должно производитья неявно.
FR>Так эта разница как раз и дает возможность легко делать обобщенные функции, так что реально это очень большая разница.
Ты ообще не понял что он говорил. Прочти еще раз сказанно им. Там об обощенности вообще ни слова. Обобщенность там как раз планируется задаваться явно (как в шарпе, 1 в 1). Там говорится, что ассоциация интерфейсов с кокретными классами будет производиться неявно. То есть ты не будешь обязан прописывать в классе что он реализует интерфейс ICompoarable[T], как это ты обязан делать в Шарпе. Вместо этого класс будет считаться реализующим интерфейс если у него есть необходимый список методов (совпадающий по сигнатуре). Собственно очень похожая идея уже реализована в новй версии VB.NET. Едея в общем-то красивая, но имеющая пробелмы в плане быстродействия. Хотя в рамках VM их решить можно. Проблема в том, что VM дотента и яывы на это плохо рассчитаны.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Ну питон традиционно оттуда разные вещи утягивает
VD>Вот только непоследовательно. Надо было начинать с паттерн-матчинга и алгеброических типов.
Ну это он решает.
FR>>Ты статью внимательнее почитай, там есть про мотивировку и там нет цели выводить все во время компиляции.
VD>Прочитал. Когда дочитал до конца возник резонный вопрос. Ну, ты знаешь какой. Такое ощущение, что товарищь блуждая по Интернету набрел то ли на Немерле, то ли на Скалу. Синтаксис во многом 1 в 1 содран.
Ну конечно как же без N
VD>А вообще, товарищь правильным путем свои мысли развивает. Медленно, правда.
VD>Мне вот интересно, что ты вдруг вспомнил о статьях двух-годичной давности?
А у меня глюк приключился месяц декабрь я увидел, а год мимо проскочил, показалась что статьятолько что вышла, тем более набрел я на нее очень окольными путями
VD>И еще интересно, что ты после этого скажешь о старой доброй теме статика вс. динамика, если даже создатель твоего любимого языка явно плывет по течению к статической типизации и выводу типов? Отстаешь ты явно от своих кумиров.
Мне там интересным показалась не само введение статики, а именно расуждения про типы. А по поводу статики для питона необходимости нет, но и мешать тоже не будет.
Re[4]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Так вроде все на поверхности, но недостатки не вообще статической типизации а схемы "тип == класс" которая ограничена и менее общая чем схема "тип по сигнатуре", по второй схеме обобщенные функции вводятся легко и естественно. Ну и кроме того обозначены и некторые проблемы которые например в том же окамле (а он типизирован по второй схеме) не разрешены.
VD>Мне кажется, что ты хочешь видеть то, чего нет в этих статьях и не хочешь то, что там есть.
Мне тоже самое кажется насчет тебя
VD>Ни одного слова про недостатки статической типизации там не сказано. Там просто рассуждается о том, что схема Хаскеля (Хаскель, правда не называется, но это именно его схема) отлично подходит для введения статической типизации в ранее полностью динамический язык вроде Питона.
VD>Про ОКамл ты тоже что-то путаешь. Привди, плиз цитаты.
Не понял какие цитаты?
VD>Про вывод обобщенных типов тоже. Он как раз предлагает задавать сигнатуры обобщенных типов явно. Что 1 в 1 копирует дотнетуно-явовскую схему. И вообще интерфейсы описанные товарищем 1 в 1 явновские/дотнетные. Даже ограничения и те скопированы (вплодь до ключевого слва where). Тоько принцип их применения скорее похож на развитие идей классов типов Хаскеля. В прочем классы типов Хаскеля тоже имеют очень много общего с интерфейсами дотнета/явы. Так что все логично.
Да все логично но не так как это предполагается ввести в питон. Общее конечно есть, но и коренных различий тоже полно.
Re[9]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, FR, Вы писали:
FR>>То есть это шире чем объектные классы окамла. Те же интерфейсы у ван Россума включают не только сигнатуры методов но и тела, что позволяет в интерфейсе прописывать и Design By Contract и вообще более жесткие ограничения.
FR>Товарищи поставившие минус счем не согласны то?
Я бы обратил внимание на два момента.
1. Переверание слов ван Россума. Про тела он ничего не говорил.
2. Непонимание того как работает система типов Хиндли-Миллера в ОКамле. ОКамл легко решает задачи подобные приведенной тобой. Там есть алгеброические типы которые можно использовать как безопасные юнионы. А так же он сам выводит наиболее общий класс (считай интерфейс). Так что если ты напишешь метод который способен оперировать разными типами, то ОКамл сам распознает это и породит обобщенный метод. А вот как раз этот плано-Питон на подобное похоже не способен. Он требует явного задания информации об общении.
Что до Design By Contract, то ван Россум предложил накладывать ограничения на методы интерфейса, а не позволять делать тела у методов интерфейсов. Это разные вещи. Причем перво — это очень грамотное решение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Ну у ван Россумма интерфейс понятие более широкое чем в Шарпе, он хочет под интерфейс подвести не только сигнатуру но и контракт.
VD>Я вот прочел статью и понял, что просто у тебя каша. У твоего ван Россумма как раз интерфейс 1 в 1 явовский (шарп ковариантности не пдоупскает, а так бы был и шарповским). Разница только в применении. Это твой ван Россумма предлагает ассоциировать интерфейсы с конкретными объектами динамически (ну, или с конкретными классам статически, но неявно, а по утиному). Собственно в этом есть рациональное зерно, так как в системе типов дотнеа и явы есть дна засада. Нельзя без создания адаптера ассоциировать интерфейс с уже имеющимся (в бинарном виде, например) классом. В Хаскеле и мечтах ван Россумма это возомжно. В этом заключается приемущество. Недостаток же заключается в том, что такая ассоциация во-первых может получиться случаяно (с вытекающей из этого семантической ошибкой), а во-вторых не гибка (надо совпадение сигнатур методов, а этого может не быть).
Нет совпадение сигнатур методов не нужно, нужно чтобы объект содержал все сигнатуры которые есть в интерфейсе, то есть то же "утиное" сопоставление.
VD>В Хаскеле это сделано более элегантно. Этот язык заставляет объявлять ассоциазции типов и интерфейсов (классов типов в его терминалогии) явно. Это с одно стороны оставляет полный контроль, а с другой дает большую гибкость нежели в явопдобных системах типов. Однако это плохо вяжется с динамикой в стиле Питона. Но тут уж надо быть последовательным. Рассуждения ван Россумма явно говорят о том, что он склоняется к отказу от динамики в пользу вывода типов с частичной их аннотацией (1 в 1 идея раелизованаая в Немерле). Вот только тут все зависит от того насколько он будет последователен в своих размышлениях и действиях. Если будет последователен, то через несклько лет Питон превратится в нечто очень похожее на Немерле . Если нет, будет еще тот езжоужжик который скорее соберет все худшее из двух миров.
Ну это уже твои фантазии.
VD>>>А разница должна заключаться тольк в том, что сопоставление кокретного объекта и этого интерфейса/класса должно производитья неявно.
FR>>Так эта разница как раз и дает возможность легко делать обобщенные функции, так что реально это очень большая разница.
VD>Ты ообще не понял что он говорил. Прочти еще раз сказанно им. Там об обощенности вообще ни слова. Обобщенность там как раз планируется задаваться явно (как в шарпе, 1 в 1).
Скорее как в С++
Но это только для параметризировнных типов.
VD>Там говорится, что ассоциация интерфейсов с кокретными классами будет производиться неявно. То есть ты не будешь обязан прописывать в классе что он реализует интерфейс ICompoarable[T], как это ты обязан делать в Шарпе. Вместо этого класс будет считаться реализующим интерфейс если у него есть необходимый список методов (совпадающий по сигнатуре). Собственно очень похожая идея уже реализована в новй версии VB.NET. Едея в общем-то красивая, но имеющая пробелмы в плане быстродействия. Хотя в рамках VM их решить можно. Проблема в том, что VM дотента и яывы на это плохо рассчитаны.
Так это и есть основная фишка.
Re[10]: Как скрестить ужа и ежа или статическую и утиные тип
VD>Я бы обратил внимание на два момента. VD>1. Переверание слов ван Россума. Про тела он ничего не говорил.
Посмотри код:
interface I:
def foo(x: int) -> str:
"The foo method."
assert x > 0
Выделенное уже тело метода интерфейса. И описание
Here the metaclass would replace C.foo with a wrapper that (1) checks that exactly one argument is passed, (2) checks that it is an int, (3) executes the body of the method declared in the interface (which in this example checks that x is > 0), (4) calls the method implementation; (5) checks that the return value is a string; and (6) returns the return value.
VD>2. Непонимание того как работает система типов Хиндли-Миллера в ОКамле. ОКамл легко решает задачи подобные приведенной тобой. Там есть алгеброические типы которые можно использовать как безопасные юнионы. А так же он сам выводит наиболее общий класс (считай интерфейс). Так что если ты напишешь метод который способен оперировать разными типами, то ОКамл сам распознает это и породит обобщенный метод. А вот как раз этот плано-Питон на подобное похоже не способен. Он требует явного задания информации об общении.
Окамл насколько я помню через ж... может решать эту проблему.
VD>Что до Design By Contract, то ван Россум предложил накладывать ограничения на методы интерфейса, а не позволять делать тела у методов интерфейсов. Это разные вещи. Причем перво — это очень грамотное решение.
Он предложил и то и другое.
Re[8]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, FR, Вы писали:
FR>Мне там интересным показалась не само введение статики, а именно расуждения про типы.
Тогда очень советую почитать про классы типов Хаскеля. Там все на довольно высоком научном уровне спроектированно. Плюс это уже работает, т.е. гарантированно корректно и не противоречиво.
FR>А по поводу статики для питона необходимости нет, но и мешать тоже не будет.
Аднако автор Питона с тобой не вполне согласен. И я его всецело поддерживаю.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, FR, Вы писали:
VD>>Мне кажется, что ты хочешь видеть то, чего нет в этих статьях и не хочешь то, что там есть.
FR>Мне тоже самое кажется насчет тебя
Возможно, возможно... что статья не про то как к Питону статическую типизацию приделать, а про проблемы этой самой статической типизации. Значит я не уловил. Тебе виднее.
FR>Не понял какие цитаты?
Ну и кроме того обозначены и некторые проблемы которые например в том же окамле (а он типизирован по второй схеме) не разрешены.
Твои слова? Ну, вот и приведи цитаты из этих статей где автор говорил о проблемах ОКамла.
FR>Да все логично но не так как это предполагается ввести в питон. Общее конечно есть, но и коренных различий тоже полно.
Ты почему-то думашь что путь Питона какой-то особенный. Меж тем все украдено до него. Он просто пытается прикурутить статическую типизацнию и вывод типов к Питону. При этом он выбирает из имеющихся альтернатив.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, FR, Вы писали:
FR>Нет совпадение сигнатур методов не нужно, нужно чтобы объект содержал все сигнатуры которые есть в интерфейсе, то есть то же "утиное" сопоставление.
Это и есть совпадение сигнатур. Блин, поспорить что ли охота?
FR>Ну это уже твои фантазии.
Ну, ну.
FR>Скорее как в С++ FR>Но это только для параметризировнных типов.
Тебя так и прет поспорить ни о чем. Адреналину что ли нехватает? Какая разница С++ или Шарп? Речь идет о явном задании параметров типов. В отлчии от этого подхода ОКамл и Хаскель подразумевают что все типы бобщены по умолчанию и что переменные типы как бы есть априори. Выражаясь наукобразным языком — все типы стоят под квантором всеобщности.
О С++ же я не упоминал по ричини того, что шаблоны в нем вещь чисто текстуальная. В рантайме их нет. А в Питоне явно говорится о интерфейсах аналогичных донтентым — существующим в рантайме. Ну, да это уже дело десятое. Нет никакого желания втягиваться в дискуссию С++ вс. Шарп.
FR>Так это и есть основная фишка.
Я бы сказал что это хорошая идея. Она цельнотянутая из Хаскеля, но это дело десятое. Главное, что это не основаная его идея. А основную его идею ты похоже просто не хочешь видеть. Основаня идея заключается в том, чтобы внести в Питон статическую типизацию. Она конечно будет не обязательной, но явно автор Питона понимает, что это полезная вещь. Ты же упоно не хочешь признавать этого и видишь в его статье что угодно но не это.
Ты во всю плевался в Boo, а когда автор Питона предложил по сути аналогичные вещи ты вдруг нашел это предложение интересным, но усмотер в нем все что угодно, но не суть.
ЗЫ
На самом деле действительно интересная тема. Она показывает, что правильных идей мало и люди разными путям но все же выходят на них. Питоновцы, Хаскелевцы, Явщики, Дотнетчики, Немерлисы и Скалолазы все по тихоничку движутся в одном в одном направлении, но с разных сторон. И потихоничку они приходят к очень похожим решениям. Каждый со своим колоритом, но все же к очень похожим. Интерфейсы, классы типов, вывод типов, статическая типизация... все это правильные решение и все ползут в этом направлении. Питон снизу на пузе. Дотнет сбоку на мешке с баксами. Немеле и Хаскель сверху на научном багаже. Но все движутся в одном направлении.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Как скрестить ужа и ежа или статическую и утиные тип
FR>interface I:
FR> def foo(x: int) -> str:
FR> "The foo method."
FR> assert x > 0
FR>
FR>Выделенное уже тело метода интерфейса. И описание
Ты невнимательно читал и не уловил суть. Это всего лишь средство более гибко оформить пре-условия. Там есть такое замечание:
Methods in interfaces should not declare "self" as an explicit argument.
Как ты думаешь чего ты лешаешся не имея возможности обратиться к self? Правльно, ты не можешь использовать члены интерфейса и темболее класса. Все что ты можешь — это проверить значение параметров. А зачем он решил развать это "телом" он тоже объясняет:
Design By Contract, Eiffel's approach to integrating pre- and post-conditions into the type system, was recommended frequently (also in the past) and I would love to do something with this. Thinking aloud, perhaps the body of a method declaration in an interface could be interpreted as code implementing the precondition? I had previously thought that interfaces could use this syntax:
Now it seems easy enough to extend this by allowing additional code in the body following the docstring, for example:
interface I1:
def fumble(name: str, count: int) -> bool:
"""docstring"""assert count > 0
assert name in ReferenceTable
(But what to do for the postcondition? Perhaps we could use a nested function with a designated name, e.g. check_return().)
FR>Окамл насколько я помню через ж... может решать эту проблему.
Ты не правильно понимаешь. У ОКамла есть три проблемы:
1. Все идентификаторы должны быть уникальны или полностью квалифицироваться именем модуля. То есть ты не можешь создать два типа или две функции с одинаковыми именами.
2. В следствии п. 1 и карринга невозможна перегрузка функций.
3. Недопустимы неявные приведения типов.
4. Имеется дурацкий запрет на upcast.
5. Арифмитические операторы недопускают пергрузку. Для флоатов используется одтедьный оператор.
В остальном язык более чем полноценнен. Все ограничения вызваны особенностями алгоритма вывода типов для системы тпов Хиндли-Миллера.
Вывод же полиморфных функций у них происходит в автомате. Они выводят так называемый наиболее близки общий тип и реалуют функцию (сткрыто) для него. То есть как бы они автоматически формируют невидимый интрфейс включающий используемые функции и неявно реализует этот интерфейс во всех совместимых типах. Или, если выражаться в терминалогии скриптов, они используют утиную типизацию но во время компиляции.
VD>>Что до Design By Contract, то ван Россум предложил накладывать ограничения на методы интерфейса, а не позволять делать тела у методов интерфейсов. Это разные вещи. Причем перво — это очень грамотное решение.
FR>Он предложил и то и другое.
Ты его не верно понял. См. выше. Это очень ограниченные тела в которых по сути можно только контролирвоать параметры.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
