почему? java - это ООП :)

Нет

Ну вернее ооп это не java

* не только джава

Java - язык

java язык, а я томат

ага ооп язык, где есть примитивы, статики, лямбды.

вики врет? Java — строго типизированный объектно-ориентированный язык программирования.

мультипарадигменный)

конечно вики не врёт, что ты

я бы тебе показал вики нашего проекта

вот ему точно не стоит верить

Лол, вы сначала с дефиницией ООП определитесь

Ну а в чем проблема? Обёртки для примитивов есть, те же статики используются для реализаций паттернов ООП, они все равно являются объектами, ну лямбды - ООП с блэкджеком и .. лямбдами

в интерфейсах реализацию можно делать))

даже практически трейты))

самое забавное читая философия java там в первых главах рассказывается почему в java не нужно множественное наследование как в c++

а потом бац и оказывается надо чтобы в se в паре мест код по красивей был без лишнего дублирования

припоминаю - в том же абзаце вроде пишется. почему в Java нет указателей

даже практически трейты))

И каким образом в дефолтной реализации интерфейса ты получишь доступ к данным?

а потом бац и оказывается надо чтобы в se в паре мест код по красивей был без лишнего дублирования

а можно поподробнее?

поэтому я написал "практически"

Ок, наезд был лишним )

а можно поподробнее?

например вот http://softwareengineering.stackexchange.com/questions/233053/why-were-default-and-static-methods-added-to-interfaces-in-java-8-when-we-alread

ty

можно еще погуглить

я через пару часов почитаю, благодарю

там идея в том что было 2 метода сортировки один у листа другой у коллекции которые были очень похожи

но их приходилось копипастить потому что для разных реализаций нельзя было наследоваться от двух мест

вообщем там написано)

Тут новая статейка https://martinfowler.com/bliki/FunctionAsObject.html

Ничего нового, но ближе к ооп

Ничего нового, но ближе к ооп

ты так говоришь, как будто ооп это что-то хорошее

ты так говоришь, как будто ооп это что-то хорошее

Да, вполне хорошее

ООП без типажей не нужно

Так, а типажи это что?

Сейчас даже у функционалка смотрится получше, чем потуги оппшников

Так, а типажи это что?

лол

лол

Отлично объяснил, спасибо)

Вижу что-то в расте, похоже на интерфейсы

Или тайпклассы в хаскеле, это оно?

Да, тайпклассы в хаскеле или трейты в расте (или имплисит в скале)

Да, тайпклассы в хаскеле или трейты в расте (или имплисит в скале)

А типажами они где называются?

это просто перевод "тайпкласса"

Трейты не очень слово, ибо путаница с трейтами из рубей

Окей, никогда не думал о переводе тайпклассов

Так я не понял связи ооп и тайпклассов

Т.е. связь ооп с интерфейсами ты понимаешь, а с типажами нет?

Ну даже просто интерфейсы в жаве

Сейчас даже у функционалка смотрится получше, чем потуги оппшников

Вот эт ваще какой-то стремный наброс, какие потуги?)

Т.е. связь ооп с интерфейсами ты понимаешь, а с типажами нет?

С интерфейсами тоже слабенькая

Вот эт ваще какой-то стремный наброс, какие потуги?)

Ну, например, у функциональщиков нет той проблемы с итераторами, их решение через трансдьюсеры вполне выруливает

С интерфейсами тоже слабенькая

Лол. Дай угадаю, крестовик?

Лол. Дай угадаю, крестовик?

Нет

Ну, например, у функциональщиков нет той проблемы с итераторами, их решение через трансдьюсеры вполне выруливает

Итераторы которые мутабельные? Они говно, надо юзать имутабельные и итераторы делают тоже самое что трансдьюсеры

Ладно, разговор ни о чём, "ООП" сегодня это пердёшь в воздух, так что сравнивать нужно конкретные проявления (протимную модель, модель кея, классовую модель).

Итераторы которые мутабельные? Они говно, надо юзать имутабельные и итераторы делают тоже самое что трансдьюсеры

Нет, речь не об этом

Даже свертки если захотеть

Ладно, разговор ни о чём, "ООП" сегодня это пердёшь в воздух, так что сравнивать нужно конкретные проявления (протимную модель, модель кея, классовую модель).

Ровно как и фп

Ровно как и фп

Хотя там получше, потому что об этом просто меньше говорят

Paul Loyd, [10.02.17 23:10] Чуваки, простейшая для типажей абсолютно задача: спроектировать итератор Map<I, F> такой, чтобы он был Copyable только тогда, когда итератор I: Copyable. Аналогично с остальными производными итераторами (Filter, Flat и прочее) Paul Loyd, [10.02.17 23:11] Кроме Copyable могут быть и другие (аля ExactSize, если можно узнать кол-во оставшихся).

Хреново процетировалось, ну да ладно

ERROR: S client not available

Paul Loyd, [10.02.17 23:10] Чуваки, простейшая для типажей абсолютно задача: спроектировать итератор Map<I, F> такой, чтобы он был Copyable только тогда, когда итератор I: Copyable. Аналогично с остальными производными итераторами (Filter, Flat и прочее) Paul Loyd, [10.02.17 23:11] Кроме Copyable могут быть и другие (аля ExactSize, если можно узнать кол-во оставшихся).

А что значит Copyable?

Что элементы можно копировать

Так это свойство элементов?

+ нужно чтобы можно было пробрасывать свои атрибуты. Скажем, чтобы uniq() работал как обычный dedup нужно гарантировать свойство упорядоченности

Так это свойство элементов?

Да

Да

Так как это влияет на список?

+ нужно чтобы можно было пробрасывать свои атрибуты. Скажем, чтобы uniq() работал как обычный dedup нужно гарантировать свойство упорядоченности

Скажем, на типажах можно просто объявить типаж 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 { // реализация с буфером }

Так как это влияет на список?

Не понял, что влияет?

Элемент Copyable, это его свойство, почему оно как-то должно отражаться на контейнере?

Скажем, у тебя есть итератор по ссылкам на какой-то тип. Можно ли получить итератор по значениям зависит лишь от того, копируемый ли элемент или нет.

Если ты хочешь мапу только из Copyable, то так и должен ее описать, Map <I: Copyable>

Если ты хочешь мапу только из Copyable, то так и должен ее описать, Map <I: Copyable>

Отлично. Как мне описать это в классовом ООП?

class SpecificList <I: Copyable> implements Map <I>

Какая разницу списку, клонируемые его элементы или нет?

Так если разницы нет, то используй просто Map <I>

Oo

Ты, видимо, не понял задачу

Я может очень сонный, но совсем не улавливаю)

Ещё раз: есть итератор Iterator<T>, не важно откуда он получен. Очевидно, что на итераторе есть всякие filter(), map() и т.д., которые порождают другие итераторы, скажем map() порождает итератор Map<Iterator<T>, fn>

Задача: у этого итератора должен быть метод clone() только тогда, когда он есть у типа T

/stat@combot

combot.org/chat/-1001071233926

А что сделает clone у итератора?

Будет вызывать у всех элементов clone, чтобы получить из Iterator<&T> Iterator<T>

Если не нравится свойство клонируемости можешь другое взять, скажем частичной/полной сравнимости или эквивалентности

Ага, ну тебе нужен CloneableIterator <T: Cloneable> implements Iterator <T>

В котором описан clone

Отлично, о чём я и говорю

Это одно свойство

Теперь добавим ещё сравнимости и эквивалентности

И получаем CloneableEqOrdIterator

И дублируем так на все Map, Filter, Skip и т.д. итераторы