Уточню интересно то, что он разделяет понятие типа и понятие класса. Это насколько я понимаю похоже на хаскелевские полиморфные типы, но отличается от них. Обычно в ООП языках понятие тип и класс эквивалентны (с небольшими вариациями вроде встроенных типов) здесь же предлагается новое понятие тип под которым понимается:
a "type" is an abstract set of method signatures
то есть тип это просто соответствие сигнатур методов класса определенному интерфейсу, утиная типизация остается нас ни кто ни обязывает наследоватся от этого интерфейса, но при этом вводится контроль от очень мягкого до жесткого статического.
На практике это дает к примеру такое, можно вводить обобщенные (и притом утиные) функции работающие только с определеными сущностями, например
def min(a: iterable(T)) -> T:
.....
Re[2]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, FR, Вы писали:
FR>то есть тип это просто соответствие сигнатур методов класса определенному интерфейсу, утиная типизация остается нас ни кто ни обязывает наследоватся от этого интерфейса, но при этом вводится контроль от очень мягкого до жесткого статического.
Т.е. класс есть набор типов чтоли? Или тип один и жёстко задан? Тогда чем от класса отличается? "Не паблик" подробностями?
Не понимаю до конца идеи
Re[3]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, FR, Вы писали:
FR>>то есть тип это просто соответствие сигнатур методов класса определенному интерфейсу, утиная типизация остается нас ни кто ни обязывает наследоватся от этого интерфейса, но при этом вводится контроль от очень мягкого до жесткого статического. К>Т.е. класс есть набор типов чтоли? Или тип один и жёстко задан? Тогда чем от класса отличается? "Не паблик" подробностями? К>Не понимаю до конца идеи
Нет класс как был так и остается.
А тип абстактное понятие, важное только например при объявлении функции. Мы можем объявить функцию принимающую определенный интерфейс, так вот любой класс у которого есть все функции с сигнатурой соответствующей этому интерфейсу будет принят, иначе отвергнут (в момент компиляции или runtime исключение). В отличии от статических языков при этом утиная типизация остается в силе, класс не обязан наследоватся от данного интерфейса, нужно только чтобы он ему соответствовал.
Re[4]: Как скрестить ужа и ежа или статическую и утиные типи
FR> В отличии от статических языков при этом утиная типизация остается в силе, класс не обязан наследоватся от данного интерфейса, нужно только чтобы он ему соответствовал.
Да еще вот это совокупность классов соответствующих даному интерфейсу и есть тип. То есть понятие абстрактное и расширяемое.
Re[4]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, FR, Вы писали:
FR>>>то есть тип это просто соответствие сигнатур методов класса определенному интерфейсу, утиная типизация остается нас ни кто ни обязывает наследоватся от этого интерфейса, но при этом вводится контроль от очень мягкого до жесткого статического. К>>Т.е. класс есть набор типов чтоли? Или тип один и жёстко задан? Тогда чем от класса отличается? "Не паблик" подробностями? К>>Не понимаю до конца идеи
FR>Нет класс как был так и остается. FR>А тип абстактное понятие, важное только например при объявлении функции. Мы можем объявить функцию принимающую определенный интерфейс, так вот любой класс у которого есть все функции с сигнатурой соответствующей этому интерфейсу будет принят, иначе отвергнут (в момент компиляции или runtime исключение). В отличии от статических языков при этом утиная типизация остается в силе, класс не обязан наследоватся от данного интерфейса, нужно только чтобы он ему соответствовал.
Т.е. получается, что если у нас в фунции для параметра вызываются методы метод1 и мелод2, то получаем, что интерфейс параметра должен их включать?
И при проверке идёт не определение на то, что интерфейс состоит из 2 методово, а то что они есть?
Тогда понятней, спасиб
Re[2]: Как скрестить ужа и ежа или статическую и утиные типи
FR wrote: > На практике это дает к примеру такое, можно вводить обобщенные (и притом > утиные) функции работающие только с определеными сущностями, например > def min(a: iterable(T)) -> T: > .....
Мне это больше всего напоминает концепты из следующего C++.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[5]: Как скрестить ужа и ежа или статическую и утиные типи
FR>> В отличии от статических языков при этом утиная типизация остается в силе, класс не обязан наследоватся от данного интерфейса, нужно только чтобы он ему соответствовал.
FR>Да еще вот это совокупность классов соответствующих даному интерфейсу и есть тип. То есть понятие абстрактное и расширяемое.
Вот тут я уже запутался.
Тип — это совокупность методов опр. объекта? Или параметра метода/функции?
Просто 1-е может быть больше чем 2-е. Т.е. получаем разные типы? Но тип объекта должен быть наследником(не знаю как это сказать, но содержать больше методов, кроме тех что есть у предка) типа, который определён для параметра функции, куда этот объект передаётся, так?
Re[5]: Как скрестить ужа и ежа или статическую и утиные типи
К>Т.е. получается, что если у нас в фунции для параметра вызываются методы метод1 и мелод2, то получаем, что интерфейс параметра должен их включать? К>И при проверке идёт не определение на то, что интерфейс состоит из 2 методово, а то что они есть? К>Тогда понятней, спасиб
В общем да. Та же утиная типизация но с ограничениями.
Re[6]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, FR, Вы писали:
FR>>> В отличии от статических языков при этом утиная типизация остается в силе, класс не обязан наследоватся от данного интерфейса, нужно только чтобы он ему соответствовал.
FR>>Да еще вот это совокупность классов соответствующих даному интерфейсу и есть тип. То есть понятие абстрактное и расширяемое.
К>Вот тут я уже запутался. К>Тип — это совокупность методов опр. объекта? Или параметра метода/функции? К>Просто 1-е может быть больше чем 2-е. Т.е. получаем разные типы? Но тип объекта должен быть наследником(не знаю как это сказать, но содержать больше методов, кроме тех что есть у предка) типа, который определён для параметра функции, куда этот объект передаётся, так?
Не забывай про утиную типизацию, нас не волнует что может быть больше пусть будет, главное чтобы в классе было все что есть в интерфейсе.
Re[7]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, FR, Вы писали:
FR>>>> В отличии от статических языков при этом утиная типизация остается в силе, класс не обязан наследоватся от данного интерфейса, нужно только чтобы он ему соответствовал.
FR>>>Да еще вот это совокупность классов соответствующих даному интерфейсу и есть тип. То есть понятие абстрактное и расширяемое.
К>>Вот тут я уже запутался. К>>Тип — это совокупность методов опр. объекта? Или параметра метода/функции? К>>Просто 1-е может быть больше чем 2-е. Т.е. получаем разные типы? Но тип объекта должен быть наследником(не знаю как это сказать, но содержать больше методов, кроме тех что есть у предка) типа, который определён для параметра функции, куда этот объект передаётся, так?
FR>Не забывай про утиную типизацию, нас не волнует что может быть больше пусть будет, главное чтобы в классе было все что есть в интерфейсе.
И чем это противоречит тому, что я сказал? Забыл, наверное, "наследником" в кавычки взять, т.к. типы не есть классы, там множественное "наследование" будет вполне нормальным и т.п. А про суть отношения, которое я "наследованием" обозвал я написал
Re[4]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, FR, Вы писали:
FR>Нет класс как был так и остается. FR>А тип абстактное понятие, важное только например при объявлении функции. Мы можем объявить функцию принимающую определенный интерфейс, так вот любой класс у которого есть все функции с сигнатурой соответствующей этому интерфейсу будет принят, иначе отвергнут (в момент компиляции или runtime исключение). В отличии от статических языков при этом утиная типизация остается в силе, класс не обязан наследоватся от данного интерфейса, нужно только чтобы он ему соответствовал.
Вот только создатели OCaml'а и Haskell'я этого не знают...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, WolfHound, Вы писали:
WH>>Вот только создатели OCaml'а и Haskell'я этого не знают...
FR>Внешне немного похоже, но совсем не то.
Поясни, в чём принципиальная разница?
Re[7]: Как скрестить ужа и ежа или статическую и утиные типи
В том что в отличии от окамла например сохраняется присущая динамике гибкость, к примеру можно реализовать функцию принимающую или строку или файл:
def read(f: file | str) -> str:
"read data from a file"
То есть это шире чем объектные классы окамла. Те же интерфейсы у ван Россума включают не только сигнатуры методов но и тела, что позволяет в интерфейсе прописывать и Design By Contract и вообще более жесткие ограничения.
Re[3]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, Cyberax, Вы писали:
C>FR wrote: >> На практике это дает к примеру такое, можно вводить обобщенные (и притом >> утиные) функции работающие только с определеными сущностями, например >> def min(a: iterable(T)) -> T: >> ..... C>Мне это больше всего напоминает концепты из следующего C++.
А мне это напоминает существующую Скалу. Особенно вот этот пример:
def min(a: T, b: T) -> T:
if a < b:
return a
else:
return b
и дальнейшие сомнения:
What about min(1, 2.5)? That ought to be valid and return a float. I guess this means that there should be some kind of typing hierarchy that explains how the various numeric types are embedded in each other. The VM already knows about these coercion rules, but the trick is to build them into the type system. I think I would like to do this using a mechanism separate from inheritance, since I really don't think that it is a good idea to require that int is a subclass of float and float a subclass of complex. But the mechanism should also be open to user-defined types; there shouldn't be mechanisms in Python that the user cannot extend (not many, anyway).
В Скале накрутили нехилую иерархию типов, в которой есть общий корень scala.Any (все наследники от него) и общий крайний scala.Nothing (который является наследником от всех). И для того, чтобы параметризованные методы могли работать с родственными типами там понапридумывали разных ко- и контра-вариантностей, ограничений на типы параметров сверху и снизу... В общем, лично у меня в голове не укладывается
Как бы в следующем Питоне не получить чего-нибудь подобного.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, eao197, Вы писали:
E>В Скале накрутили нехилую иерархию типов, в которой есть общий корень scala.Any (все наследники от него) и общий крайний scala.Nothing (который является наследником от всех). И для того, чтобы параметризованные методы могли работать с родственными типами там понапридумывали разных ко- и контра-вариантностей, ограничений на типы параметров сверху и снизу... В общем, лично у меня в голове не укладывается
E>Как бы в следующем Питоне не получить чего-нибудь подобного.
А что тебя в этом пугает? Наоборот всё логично.
И вариантности там в тему вполне.
Re[8]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, FR, Вы писали:
FR>То есть это шире чем объектные классы окамла. Те же интерфейсы у ван Россума включают не только сигнатуры методов но и тела, что позволяет в интерфейсе прописывать и Design By Contract и вообще более жесткие ограничения.
Поясни выделенное, плиз
В контракте будет конкретная реализация чтоли?
Re[9]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, FR, Вы писали:
FR>>То есть это шире чем объектные классы окамла. Те же интерфейсы у ван Россума включают не только сигнатуры методов но и тела, что позволяет в интерфейсе прописывать и Design By Contract и вообще более жесткие ограничения.
К>Поясни выделенное, плиз К>В контракте будет конкретная реализация чтоли?
Вот пример из статьи:
interface I1:
def fumble(name: str, count: int) -> bool:
"""docstring"""
assert count > 0
assert name in ReferenceTable
При реализации метода интерфейса в классе, тело метода из интерфейса будет вызыватся как предусловие.
Re[10]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, FR, Вы писали:
FR>>>То есть это шире чем объектные классы окамла. Те же интерфейсы у ван Россума включают не только сигнатуры методов но и тела, что позволяет в интерфейсе прописывать и Design By Contract и вообще более жесткие ограничения.
К>>Поясни выделенное, плиз К>>В контракте будет конкретная реализация чтоли?
FR>Вот пример из статьи:
FR>
