Ну тут легко решается adhoc полиморфизмом, но функции будут не в объекте.

Это всё adhoc полиморфизм и так

И проблема, как видишь, не решается

В крестах можно первую проблему ещё как-то решить, но через жопу (определять методы в зависимости от того, если метод у типа или нет), но вторая всё равно не решается.

function clone<T: Cloneable> (i: Iterator<T>): Iterator...

Решает вполне

Так можно решить только для свойств самого типа, но не итератора. Скажем, если есть свойство ExactSize для итераторов, которые могут сказать, сколько элементов осталось, то какие-то производные итераторы (скажем Map) это свойство сохраняют, а какие-то (Filter) — нет.

Т.е. придётся эти все функции вот так выносить.

(где тут ООП, кстати, лол?)

Хз, задача к ооп как-то боком вообще)

Эм. Т..е как это каким боком?

Ну это ж про систему типов

Пример того, что даже базовые концепцие как итераторы в ООП ведут к диким костылям

К дублированию иерархий (уродливые CopyableEqOrdMap)

Ну и нифига не расширяемый подход, ибо чтобы своё свойство притащить, придётся продублировать все итераторы.

Ну это ж про систему типов

Я не знаю, что ты подразумеваешь под "ООП", но факт прост: в классовом ООП эта задача решается негибкими костылями и дублированием всего и вся.

В прототипном тоже

Я не знаю, что ты подразумеваешь под "ООП", но факт прост: в классовом ООП эта задача решается негибкими костылями и дублированием всего и вся.

Покажи кстати пример на хаскеле того, что ты хочешь

Я так проще пойму

Покажи кстати пример на хаскеле того, что ты хочешь

Упрощенный есно)

Не надо фул реализацию)

Скажем, на типажах можно просто объявить типаж Sorted и сделать что-то вроде: impl<I: Iterator + Sorted> Sorted for Filter<I> {} impl<I: Iterator + Sorted> Sorted for Take<I> {} impl<I: Iterator + Sorted> Sorted for Skip<I> {} ... А потом: impl<I: Iterator + Sorted> Uniq { // реализация dedup } impl<I: Iterator + !Sorted> Uniq { // реализация с буфером }

Ну вот это пример на расте, концепция та же

Ну и, соб-но, потом, получив итератор, сделать it.uniq() и получить итератор по уникальным значениям, который в зависимости от итератора будет либо dedup делать, либо дорогой полноценный uniq. (диспетчеризация, разумеется, в компайлтайме)

А, так ты сам привел ооп пример

Тогда в чем вопрос?)

Ну вот в расте это сделали, клево)

А, так ты сам привел ооп пример

Типажи как бы не классовое ооп.

Ооп про взаимодействие объектов

А сичтать его ооп или нет — похрену, ибо под "ооп" и так всё что угодно понимают

Ооп про взаимодействие объектов

Может дашь определение ооп?

А не классы там или преобразования

Ну вот в расте это сделали, клево)

И в хаскеле. И в скале (но в скале дерьмово итераторы спроектированы, так что там не заработает так)

1. EverythingIsAnObject. 2. Objects communicate by sending and receiving messages (in terms of objects). 3. Objects have their own memory (in terms of objects). 4. Every object is an instance of a class (which must be an object). 5. The class holds the shared behavior for its instances (in the form of objects in a program list) 6. To eval a program list, control is passed to the first object and the remainder is treated as its message

Тут в идеале бы s/class/type

1. EverythingIsAnObject. 2. Objects communicate by sending and receiving messages (in terms of objects). 3. Objects have their own memory (in terms of objects). 4. Every object is an instance of a class (which must be an object). 5. The class holds the shared behavior for its instances (in the form of objects in a program list) 6. To eval a program list, control is passed to the first object and the remainder is treated as its message

1. Т.е. всякие js и даже кресты пролетают? 2, 6. Тут вообще ни один мейнсктрим (кресты, джава) не пройдут, ибо это явно про акторную модель, соб-но классчиеское ООП. 3. Лол. И стурктуры имеют. И что? 4. Всё прототипное ООП в топку. Типажи тоже, ибо классов нет.

1. Т.е. всякие js и даже кресты пролетают? 2, 6. Тут вообще ни один мейнсктрим (кресты, джава) не пройдут, ибо это явно про акторную модель, соб-но классчиеское ООП. 3. Лол. И стурктуры имеют. И что? 4. Всё прототипное ООП в топку. Типажи тоже, ибо классов нет.

Все - объект, не наоборот

Все - объект, не наоборот

int объект?

int объект?

не int а number

Вполне

не int а number

именно int. Крестовый/сишный int

Вполне

С чего вдруг примитив стал объектом?

Он не может иметь методы/принимать сообщения

С чего вдруг примитив стал объектом?

Потому что все - объект

Потому что все - объект

Ты библию прочитал что ли?

1. всё объект 2. но это не объект 3. это объект, потому что (1)

Он не может иметь методы/принимать сообщения

2.+(3)

2.+(3)

nope. Оператор в крестах это не функция, как бы ты этого не хотел

Передать его нельзя, сигнатуру не описать. + сам компилятор о нём знает

Это уже детали реализации

Ну, мы же и говорим про конкретный язык

т.е. с++ не ООП язык, так?

Нет

Ну, мы же и говорим про конкретный язык

Так и чем + не будет механизмом отправки сообщения объекту числа?

Никто ж не сказал, что я через точку вызывать их должен

Или даже наследовать мочь

Этот объект мало может? Ну да, он такой вот маленький пока что, но мы можем обернуть и сделать объекты сложнее и умнее

Или даже наследовать мочь

Что?

Ну мы же не на кофейной гуще гадаем, есть стандарт, в котором чёрным по белому написано, что есть примитивы и есть объекты.

Что?

Что классы должны или не должны наследоваться

Ну, мы же и говорим про конкретный язык

ааа

Ну мы же не на кофейной гуще гадаем, есть стандарт, в котором чёрным по белому написано, что есть примитивы и есть объекты.

?

Это где?

Что классы должны или не должны наследоваться

Унаследуй мне от int?

Унаследуй мне от int?

Что?

Новый тип

Унаследуй от int

Зачем? Оо

ERROR: S client not available

Ладно, слушай. Алана Кея все читали

И Алан Кей не имеет никакого отношения к современному ООП

Эти принципы — это принципы акторной модели

В flowtype можно что-то вроде такого алиаса: type NewInt = int & {}

Эти принципы — это принципы акторной модели

Да, отлично

В flowtype можно что-то вроде такого алиаса: type NewInt = int & {}

откуда int возмётся в flow, не понял?

И Алан Кей не имеет никакого отношения к современному ООП

Это как это ооп так изменилось?)

Кто менял?)

В flowtype можно что-то вроде такого алиаса: type NewInt = int & {}

нет

откуда int возмётся в flow, не понял?

Точно, number имел ввиду (

Кто менял?)

Мейнстримовые языки?

Не важно как называть вещи. Если все называют бублик уткой, значит теперь это утка.

Мейнстримовые языки?

Они просто процедурщину максимально хайпят

Точно, number имел ввиду (

Я чёт расстроился в последнее время в flow

undefined включить в maybe тип, буэ

+ нормально не описать эвентэмиттер

ну ладно, это не по теме

+ нормально не описать эвентэмиттер

? О.о

? О.о

Ну, нужно чтобы описание было что-то вроде: class EventEmitter { on('error', (Error) => void): void; ... } class A extends EventEmitter { on('data', (number) => void): void; }

нет

Если ты про int, то я number имел ввиду

Даже в TS подобное сделать можно (правда придётся таки описать on(ev: string, fn: Function), но специализация заработает.

Разве флоу не умеет понимать строковые литералы как тип?

Или не в том проблема?

В A будет аля class A extends EventEmitter { on (ev: 'data'|'error') }

@mkusher а ты на котлине не пишешь?)

@mkusher а ты на котлине не пишешь?)

Неа)

а че? не нравится?

Ну, задач нет, я же сейчас в гуще фронтенда

В A будет аля class A extends EventEmitter { on (ev: 'data'|'error') }

Во-первых, не получится специфицировать кэллбек, а всё ради этого. А, во-вторых, ещё нельзя сделать declare для существующих и доопределить события эти. В итоге все EE нетипизированые

Не важно как называть вещи. Если все называют бублик уткой, значит теперь это утка.

Просто под mvc тогда можно подразумевать все, что на хабре пишут, а Flux тогда действительно проблему решает)

И прям новое слово в интерфейсах

Просто под mvc тогда можно подразумевать все, что на хабре пишут, а Flux тогда действительно проблему решает)

когда критическая масса людей начнёт включать MVVM и MVP в MVC, то это тоже станет MVC, хоть название и потеряет смысл