Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
В общем, такая тема. в джаве есть класс А, у него метод а б в.
я хочу чтоб когда я из объекта класса А дергал метод а у меня исполнялся чуть-чуть мой код, а потом код метода а.

ну очевидно делаем типО обёртку Б наследуемся от интерфейса класса А, как вариант. и переписываем метод а, присовывая туда свой код а потом вызывая метод экземпляра объекта класса А.

во внешнем классе делаем Б б, б.а

работает.

ну или просто адаптер где даже наследвать ничего не буду просто создам метод а и там вызову внутрях метод а уже экземпляра класса А.

если не ошибаюсь, это всё же адаптер. (или адаптор?).

теперь берем скалу. в скале можно сделать как в джаве. и оно даже будет работать. но еще в скале есть неведомя вырвиглазная фигня под названием имплисит класс. т.е. я могу без интерфейсов наследований и прочего барахла на экземпляры класса А навешивать уже свои методы. Не совсем то что выше, но пойдет. т.е. у меня заюзан объект класса А, и мы к этому объекту класса А добавляем метод "аМодифайдСомхау", внутри которого вызывается собссно, кастомный код, а потом вызывается метод объекта класса А. Т.е. я в своем кастомном классе создал имплисит класс (ну или просто сразу имплисит класс если контекст не нужен) с нужной сигнатурой, потом в класс-жертву заимпортил его и вуаля у меня появляется на всех объектах этого класса-жертвы метод "аМодифайдСомхау".

теперь вопрос, этот имплисит класс он по категории шаблонов как называется? по-идее, если добавляем новый метод это уже не делегат. и не адаптор (или адаптер?). тогда кто он? наследование тут тоже сказать как то не хочется бо это в позиции ООП не наследование ИМХО.
27 янв 19, 16:02    [21795209]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
mayton
Member

Откуда: loopback
Сообщений: 42343
Scala является мультипарадигменным языком.
И это позволяет ей выкидывать фортели которые могут непрокатить в других языках.

По виду то что ты описал похоже на duck typing хотя я не уверен что это оно.
27 янв 19, 18:55    [21795288]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
ну типа того.

если образно есть репозиторий хибера. туда можно класть ТОЛЬКО сущность (объект заданного типа) что хибер положит в базу.

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

мы в тот же метод кладём просто другого класса объект и оно его принимает не смотря на то что у нас даже метода с такой сигнатурой нет.
27 янв 19, 19:01    [21795290]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
mayton
Member

Откуда: loopback
Сообщений: 42343
Приведи лучше фрагмент кода. Реально. 1 строчка кода стоит десятка текстовых каментов.
27 янв 19, 19:35    [21795302]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
maxkar
Member

Откуда:
Сообщений: 154
andreykaT
теперь вопрос, этот имплисит класс он по категории шаблонов как называется?


Никак класс не называется. Потому что сам по себе класс никому не интересен (он в сигнатурах методов не используется). А то, что вы описываете, называется extension method (метод расширения).

И не надо путать extension method с implicit conversion (неявное приведение типа) - эти механизмы решают разные задачи (добавить метод или привести значение к другому типу), хотя оба и могут быть реализованы с использованием implicit class (implicit conversion не всегда может быть реализована через implicit class).
27 янв 19, 21:14    [21795355]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
забыл ник
Member

Откуда:
Сообщений: 3024
maxkar, прав, это называется extension method.,
369
Это такой маленький шажок в сторону паттерна typeclass, почитать можно здесь, который позволяет решить весьма известную проблему, которая состоит в том, чтобы найти решение как расширить функционал, не меняя исходный код и не теряя
type safety.

Вообще subtyping не очень дружит с имплиситами, есть множество corner cases. Если вы планируете использовать скалу как better-java, то не стоит, лучше возьмите Kotlin. В скале наивные рассуждения вроде "В общем, такая тема. в джаве есть класс А, у него метод а б в.
я хочу чтоб когда я из объекта класса А дергал метод а у меня исполнялся чуть-чуть мой код, а потом код метода а. " вызывают лишь улыбку. Классы, методы это все вторичное, это детали имплементации. Если брать идиоматический ФП в скале, то объект это всего лишь неймспейс для функций. ФП и наследование по большей части несовместимы, для расширения кода используется паттерн typeclass, что я упомянул вначале
27 янв 19, 22:40    [21795387]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
эээ. в отпуске не могу пока. ) постараюсь попозже как комп с иде в руки получу. в общем верно. именно то что описано тут:

автор
maxkar, прав, это называется extension method.,
369
Это такой маленький шажок в сторону паттерна typeclass, почитать можно здесь, который позволяет решить весьма известную проблему, которая состоит в том, чтобы найти решение как расширить функционал, не меняя исходный код и не теряя
type safety.


и именно это я и сделал.

делал я это поверх плея с гуис ди.

что собссно я сделал:

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

далее, я уже ЭТОТ внешний класс заинжектил в сервисный класс (где требуется небольшой доп-функционал) и заимпортил методы заинжекченного класса в теле сервисного класса, чтоб у меня появились доп-методы из имплисит класса.

собссно вопрос - а) насколько это каряво? (не будь драных инжектов гуиса всё было бы сильно красивее)
и б) какому шаблону это соответствует
29 янв 19, 13:32    [21796796]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
собссно код (сорян по памяти)

class MyTrickyServiceExtension @Inject()(dbRepo:DbRepository){

 implicit class OriginalClassExtension(someObj:SomeObjToWrap) {
   def extraMethodForOriginalClass:SomeResultObj = {
   //some activity calling methods from injected beans
  //some original activities with someObj
  println(someObj.toString)
 }
}

class VictimService @Inject()(whateverBean:WhateverBean, originalClassBean:OriginalClassBean, myTrickyServiceExtension:MyTrickyServiceExtension) {
 import  myTrickyServiceExtension._
def whateverMethod = {
   originalClassBean.extraMethodForOriginalClass
 }
}
29 янв 19, 13:42    [21796810]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
забыл ник
Member

Откуда:
Сообщений: 3024
Оо
myTrickyServiceExtension:MyTrickyServiceExtension
зачем его параметром передавать? Да и имплисит класс тут нафиг не нужен. Имплиситы это вообще не про это. Какой-то адовый микс ООП и ФП. Еще раз повторяю, забудьте про наследование и объекты. Используйте ФУНКЦИИ, которые можно кастомизировать коллбэками, что-то вроде:
def logic(onStart: => Unit = (), onFinish: => Unit = ()) = {
   onStart
   .......
   onFinish
}


В принципе это есть подобие АОП на ФП
29 янв 19, 23:10    [21797342]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
я же сказал чуть выше параметром его передавать чтоб методы имплисит класса появились внутри сервиса

да можно было бы имплисит класс не делать нестедом НО как я выше уже сказал требуется функционал блинов которые иначе не заинжектить в имплисит класс

вы верно сказали про аоп по сути он и нужен

и собственно поэтому я и сказал можно либо сделать классический ооп делегат или ооп адаптер либо же заюзать эти скальи приколюхи

всю картину использования имплиситов вот конкретно в этом примере портит требование иметь гуисовские инжекты. не будь их я бы просто в шапке сделал импорт методов и все было бы прекрасно.

ваш пример я вот смотрю и не понимаю как его применить скажем в случае когда у меня есть некий нешатаемый класс с методами и мне надо некоторые вызовы этого класса везде обернуть по всему коду во всех местах с моим подходом тут надо лишь екстеншн заинжектить и подключить импорт. ну либо заюзать ооп адаптер там на пару строк больше получается в самом адаптере

в чем плюс скального имплисита? в том что он дает очень простой способ расширить функционал существующего нешатаемого класса при этом сохранив оригинальные методы. тут ооп решение не очень удобно потому что не все и не всегда можно легко отнаследовать и расширить
29 янв 19, 23:45    [21797355]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
забыл ник
Member

Откуда:
Сообщений: 3024
andreykaT
которые иначе не заинжектить в имплисит класс

Четя совсем потерялся в вашем замысле. В Имплисит? Инжектить? WTF?
Смысл имплиситов как раз чтобы сделать абсолютно независимыми и ортогональными старый и новый код.

Мой код, конечно работает только в случае pure функций, когда нет зависимостей на внешний мир, ваши инжекты это по сути и есть зависимости.

В целом, если у вас императивный код,а судя по всему так оно и есть, вам ФП подход(с имплиситами) только усложнит жизнь, тут наследование самое правильное решение. Просто в ФП нет такого понятия, как вызвать что-то и как-то обернуть. Есть чистые функции, которые можно комбинировать, в зависимости от сигнатуры, и они не зависят от внешнего мира, поэтому и имплиситы ни от каких бинов и инжектов зависеть не могут. И в таком случае достаточно просто импорта, чтобы они оказались в скоупе.

Если вам интересно как решить вашу задачу именно в ФП подходе, попробуйте дать больше деталей, не упираясь в "бины. инжектеды" и тд, я попробую расписать как это делается идиоматически с помощью ФП
30 янв 19, 12:07    [21797623]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
mayton
Member

Откуда: loopback
Сообщений: 42343
Меня всегда интересовал motivation к использованию. Чтобы тема топика была
не из серии "хочется странненького…."

Кто может пояснить когда и где этот шаблон полезен?
30 янв 19, 12:28    [21797659]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
забыл ник
andreykaT
которые иначе не заинжектить в имплисит класс

Четя совсем потерялся в вашем замысле. В Имплисит? Инжектить? WTF?
Смысл имплиситов как раз чтобы сделать абсолютно независимыми и ортогональными старый и новый код.

Мой код, конечно работает только в случае pure функций, когда нет зависимостей на внешний мир, ваши инжекты это по сути и есть зависимости.

В целом, если у вас императивный код,а судя по всему так оно и есть, вам ФП подход(с имплиситами) только усложнит жизнь, тут наследование самое правильное решение. Просто в ФП нет такого понятия, как вызвать что-то и как-то обернуть. Есть чистые функции, которые можно комбинировать, в зависимости от сигнатуры, и они не зависят от внешнего мира, поэтому и имплиситы ни от каких бинов и инжектов зависеть не могут. И в таком случае достаточно просто импорта, чтобы они оказались в скоупе.

Если вам интересно как решить вашу задачу именно в ФП подходе, попробуйте дать больше деталей, не упираясь в "бины. инжектеды" и тд, я попробую расписать как это делается идиоматически с помощью ФП


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

в общем, вот пример задачи по-сути такой же.

у плея есть WS клиент. это хрень обычный хттп клиент где он делает вызовы колбаской типа:

ws(url).params(params).post() возвращает футуру резалт. так вот, в последнем вызове .post() мне нужно перед тем как отдать футуру резалт сделать некое действие - положить этот резалт в базу. или вообще не ходить на удаленный сервис (исходя из запроса) и взять этот резалт из другой базы.

как это сделал я -- код собссно сверху.

я сделал класс обёртку туда заинжектил бины работы с репозиториями, в обертку положил имплисит класс и там уже собссно описал всю логику.

всё работает.

но по-сути, как вы верно заметили -- это ооп подход с плюшками и сахарком скалы. и не более того.
30 янв 19, 12:57    [21797701]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
и, имхо, поправьте меня если я не прав, но имплиситы это всё же сахарок а не часть ФП. вообще, имхо: не уверен что имплиситы сами по себе это здравая задумка.
30 янв 19, 14:55    [21797836]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
забыл ник
Member

Откуда:
Сообщений: 3024
mayton
Меня всегда интересовал motivation к использованию. Чтобы тема топика была
не из серии "хочется странненького…."

Кто может пояснить когда и где этот шаблон полезен?

Ну имплиситы и typeclasses это самая мощная и интересная штука, которая есть в скале, уже одно это мотивирует к изучению) Ну а если вам хочется понять практический выхлоп, то попробую обьяснить на понятном примере.
Возьмем Java, и методы определенные на Object(hashCode, equals..), так вот, согласитесь, не каждому типу нужна эта функциональность, а если и нужна - то зачастую имплементация должна быть кастомной. Реализация Java - это костыльный костыль, каждый класс наследует дефолтную реализацию от Object, что не дает словить ошибку компиляции, когда мы кладем в мапу типы, которые не должны быть сравниваемы, ну допустим Connection или FileSystem ит.д и это потенциальный источник миллионов багов. А сделано это затем, чтобы вы могли еще ненаписанные классы использовать в HashMap.

Что же позволяет сделать скала и typeclass? - Для начала можно определить trait с некой операцией, допустим

trait Equal[A] {
def equals(obj:A, other:A):Boolean
}


Это подобие Java-интерфейса, с одной операцией, можно даже сделать дефолтную имплементацию

object DefaultEquals {
   implicit class EqualsOps(equal:Equal[A]){
   def equals(other:A) = equal == other
}
}


Implicit здесь указывает компилятору, что если у произвольного объекта с типом A есть интсанс-обертка с типом Equal[A], то в коде вы можете спокойно написать
val a = new A
 a.equals(new A) // компилятор преобразует во что-то типо new Equals(a).equals(new Equals(new A))

 

и у вас не будет ошибок компиляции, компилятор автоматически найдет ваш враппер, и вклеит метод из дефолтной имплементации.

Пока я думаю до сих пор непонятно в чем прикол, те же яйца, вид сбоку. Чтобы понять, давайте перейдем к самому интересному, допустим у нас есть HashMap[A] и нам надо определить метод
add[A](obj:A)

в который можно передать любой объект.
НО, если этот объект не имеет враппера Equal - то это будет ошибка компиляции, а не молчаливое проглатывание, как в случае Java. Если вам нужно кастомизировать вашу логику сравнения, вам нет никакой необходимости модифицировать чужой\свой код. Вы можете просто написать в своем проекте

 object Implicits{
   implicit val eq:Equal[User] = new Equal[User]{
    override def equal(u:User, u2:User) = u.name == u2.name
}
}


Метод add будет иметь следующую сигнатуру -

def add[A](obj:A:Equal)


то есть акцептается только объект с типом A, у которого определен враппер Equal[A]. Соотвественно, если вы кладете в мапу Coneection = ошибка компиляции.

Заметьте, User может быть из сторонней либы, и вы можете не иметь доступа к исходникам. Таким образом мы расширили функционал, не трогая текущий. Вообще, чем-то напоминает Visitor.

В ООП проблема расширения решается созданием общего интерфейса и наследованием от него новых имплементаций, но какой общий предок у UserDTO и Email? Поэтому в Java и ввели Object. Этот подход кривой и имеет минимум два недостатка - 1) Все классы, иначе никак не связанные должны наследоваться от единого предка 2) Когда вы пишите код, вы должны имплементировать интерфейс\экстендить класс и если класс уже написан, то его может быть проблематично поменять.

Пример с equals тривиален, теперь представьте что у вас есть задача иметь сериализатор\десериализатор json, который выдает ошибку компиляции(НЕ РАНТАЙМ), если класс не имплементирует логику сериализации. В Java это скорее всего будет рефлекшен, который свалится в рантайме, поскольку не найдет сериализатора для какого нибудь JodaTime.
С помощью typeclass делается так -

trait Serializator[A]{
def serialize(a:A):String
}

и объявлены сериализаторы для Int, Double, String.
в таком случае код
case class User(name:String, age:Int)
case class User2(name:String, age:Int, bd:Date)
serialise(User("mayton", 40)) //Compile OK
serialise(User2("mayton", 40, new Date)) // Compile ERROR


Особая прелесть в том, что если юзаются case class, состоящие из полей Int, Double и тд, которые имеют сериализаторы, то scala автоматически сгенерит сериализатор и для всего класса, без единой строки кода.
30 янв 19, 17:43    [21798108]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
забыл ник
Member

Откуда:
Сообщений: 3024
andreykaT
и, имхо, поправьте меня если я не прав, но имплиситы это всё же сахарок а не часть ФП. вообще, имхо: не уверен что имплиситы сами по себе это здравая задумка.

Создатели scala лоханулись, у слова implicit слишком много семантических значений, в последних версиях они пытаются исправить этот косяк. Из-за него идет очень много непонимания.
К ФП как таковому, implicits конечно же не относятся. Но благодаря имплиситам, в скале можно реалиовать typeclasses, которые как раз и есть ФП в чистом виде.
И да, некоторые применения implicit опасны и имеют плохую репутацию(implicit conversion), но люди не разобравшись автоматически переносят на все остальные применения. Ну примерно как в Java модификатор final имеет как минимум три семантически разных варианта использования(для переменной, метода и класса в целом)
30 янв 19, 17:47    [21798117]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
mayton
Member

Откуда: loopback
Сообщений: 42343
Это типа. Если бы у нас было-бы 10 разных типов (классов) и мы захотели-бы их всех сравнивать
то надо было бы написать 10 * 10 = 100 имплементаций equals(...) по принципу от каждого типа
к каждому. Ну ... минус диагональ это 90 штук. И минус нижний треугольник 90 / 2 = 45 имплементаций.

А с неявным кастингом мы можем просто доверится машине этих неявных имплиситов.

Верно?
30 янв 19, 17:48    [21798118]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
забыл ник
Member

Откуда:
Сообщений: 3024
andreykaT

ws(url).params(params).post() возвращает футуру резалт. так вот, в последнем вызове .post() мне нужно перед тем как отдать футуру резалт сделать некое действие - положить этот резалт в базу. или вообще не ходить на удаленный сервис (исходя из запроса) и взять этот резалт из другой базы.
.


Да зачем усложнять вообще? Это ж классика, делается все на фильтрах реквеста. Что является видоизмененным onStart;logic;OnEnd, зачем вам в фильтре какие-то внешние зависимости?
30 янв 19, 17:56    [21798126]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
забыл ник
Member

Откуда:
Сообщений: 3024
mayton
Это типа. Если бы у нас было-бы 10 разных типов (классов) и мы захотели-бы их всех сравнивать
то надо было бы написать 10 * 10 = 100 имплементаций equals(...) по принципу от каждого типа
к каждому. Ну ... минус диагональ это 90 штук. И минус нижний треугольник 90 / 2 = 45 имплементаций.

А с неявным кастингом мы можем просто доверится машине этих неявных имплиситов.

Верно?

Нет, так как там много букаф, вынесу сюда resume

Основной поинт в том, что если у класса нет implicit враппера Equals, то при вызове метода, будет ошибка компиляции
def add[A](a:A:Equal) - дословно тут сказано что метод принимает любой объект, который может вести себя как Equals

Рассматривайте Equal как behavior, как маркер аля Serialisable. Вы можете писать некие методы, ожидающие параметром объект, который обладает Equal behavior, если объект им не обладает - то получите ошибку компиляции.
30 янв 19, 18:27    [21798156]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
забыл ник
andreykaT
и, имхо, поправьте меня если я не прав, но имплиситы это всё же сахарок а не часть ФП. вообще, имхо: не уверен что имплиситы сами по себе это здравая задумка.

Создатели scala лоханулись, у слова implicit слишком много семантических значений, в последних версиях они пытаются исправить этот косяк. Из-за него идет очень много непонимания.
К ФП как таковому, implicits конечно же не относятся. Но благодаря имплиситам, в скале можно реалиовать typeclasses, которые как раз и есть ФП в чистом виде.
И да, некоторые применения implicit опасны и имеют плохую репутацию(implicit conversion), но люди не разобравшись автоматически переносят на все остальные применения. Ну примерно как в Java модификатор final имеет как минимум три семантически разных варианта использования(для переменной, метода и класса в целом)

ну давай так с этим финалом как мниимум всё ясно и однозначно. а имплиситы это каша какая то. спасибо иде. хоть как то помогает.

вообще в скале не тока с этим лоханулись. с теми же налл насинг нан эниреф энивал да это реально какие то костыли которые прикрутили потому что иначе задачу решить не смогли.
30 янв 19, 22:12    [21798315]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
или кейс классы с ограничением в 24 поля емнип как трейты по дефолту шта? )))
30 янв 19, 22:13    [21798316]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
забыл ник

Особая прелесть в том, что если юзаются case class, состоящие из полей Int, Double и тд, которые имеют сериализаторы, то scala автоматически сгенерит сериализатор и для всего класса, без единой строки кода.


а еще прелесть в том что джейсон конвертеры требуют явного имплисит объявления сериализатора(форматтера) или десереализатора. и если ты оба объявляешь то этот дебил начинает пытаться зацепить имплиситли сериализатор там где десереализатор нужен. и никак ему не объяснить как это сделать наоборот. кроме как явно. т.е. или мы класс сериализуем или наоборот. или один неявно другой явно.
30 янв 19, 22:17    [21798318]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
чот молчание.. так и не понял как мою задачу решить с ФП подходом.. если вообще можно конечно же.

собссно вопрос.

как постигнуть дзен ФП и на него перейти? может книжки какие то посоветуете. читаю одерского книжку скала но там особо подходы не описаны там в целом вот типа скала вот она умеет фп няхи а еще она реактивная и в ней есть сахарок, вот как делать класс вот как наследоваться и всё.

пытаюсь смотреть его курс на курсере пока не понял.
4 фев 19, 14:42    [21801323]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
...много математики. и не очень понятно объясняет.

так что почитать по скале? кроме скала фор импатентс. и скала камплит референз одерского.
4 фев 19, 14:43    [21801326]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
andreykaT
так и не понял как мою задачу решить с ФП подходом
разве тема топика про это?
Стартуй новый топик и изучай erlang
4 фев 19, 14:58    [21801351]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Java Ответить