Функциональное програмирование , Что за зверь такой

[settler]

Цитата korvin @ 28.04.16, 02:50

Этих разных типов в java.util.function 21 штука, ЕМНИП. У каждого свои методы, не всегда совместимые друг с другом, поэтому писать обощённый функциональный код для всего этого зоопарка весьма затруднительно.
Всё это подробно описано в статьях, ссылки на которые я давал ранее.

Зачем писать имеено функциональный код, или у тебя самоцель чтобы код был функциональный, это код как раз наборот позволяет
стандартизировать систему написанную в стиле ООП, если раньше каждый изобретал свой интерфес ,
то сейчас эти интерфесы станут стандартными, нужен тебе один имплементируй его ,
нужно больше пользуй хоть все 21, мало их расширяй хоть до посинения ,
вот накидал сходу

 class CustomPredicate implements Predicate<Person>, BiConsumer<Person, String>{
   private Person person;
   List<Set<Person>> persons= new ArrayList<>(3);
  
  
    public  CustomPredicate() {
        persons.set(0, new HashSet<>());
        persons.set(1, new HashSet<>());
        persons.set(2, new HashSet<>());
    }
    @Override
    public boolean test(Person p) {
        if(p.getFirstName().compareTo(this.person.getFirstName())==-1)
          return false;
        return true;
    }
    public Person getPerson() {
        return person;
    }
    public void setPerson(Person person) {
        this.person = person;
    }
    @Override
    public void accept(Person p, String u) {
         String phoneCode=null;
         switch (u) {
        case "us":
            phoneCode="001";
            break;
        case "gb":
            phoneCode="041";
            break;
        case "il"   :
            phoneCode="972";
        default:
            break;
        }
        
         p.setPhone(phoneCode+p.getPhone());        
    }

потом эти стандартный интерсейсы при желании очень легко можно настротить в IOC сontener ,
Да еще тех ликах ничего не говориться о кривости жава,

[applegame]

Цитата settler @ 28.04.16, 09:19

Зачем писать имеено функциональный код, или у тебя самоцель чтобы код был функциональный,

В цитате корвина ключевое слово "обобщенный".

[settler]

Цитата applegame @ 28.04.16, 09:45

Цитата settler @ 28.04.16, 09:19

Зачем писать имеено функциональный код, или у тебя самоцель чтобы код был функциональный,

В цитате корвина ключевое слово "обобщенный".

не уловил смысла, поясните

[korvin]

Цитата settler @ 28.04.16, 09:19

Зачем писать имеено функциональный код

Затем, что он в большинстве случаев проще и удобней.

Цитата settler @ 28.04.16, 09:19

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

Достаточно одного интерфейса: (a -> b).

Цитата settler @ 28.04.16, 09:19

вот накидал сходу

И что за кашу ты накидал? Я просил провести пример реализации функции compose.

BTW, твоё «творчество» из-за мутабельности автоматически становится непригодным к использованию в Stream API, т.к. parallelStream приведёт к непредсказуемым результатам. А добавление synchronized к методам — к тормозам. Хватает тормозов из-за боксинга (угадай на кой чёрт нужны IntConsumer вместо Consumer<Integer> и прочие Stream::mapToLong), а тут ещё synchronized.

Правда у Fork/Join Framework свои особенности.

И нафига мне вооще в одной функции (или ХЗ как назвать CustomPredicate) предикат, маскирующий компаратор, и какой-то невнятный BiConsumer. Такое ощущение, что ты просто чего-то от балды нафигачил. Ты же понимаешь, что повторный вызов accept с одним и тем же объектом Person приведёт к повторному добавлению кода к телефону?


И в довершении 40 строк против 12?

byFirstName :: Person -> Person -> Bool
byFirstName x y = firstName x < firstName y
 
withPhoneCode :: Person -> String -> Person
withPhoneCode (Person fn (code, phone)) newCode = Person fn (newCode, phone)
 
countryToPhoneCode :: String -> String
countryToPhoneCode country = case country of
    "us" -> "001"
    "gb" -> "041"
    "il" -> "972"
    _    -> ""

Действительно, никакой разницы.

Сообщение отредактировано: korvin - 28.04.16, 16:55

[D_KEY]

Цитата settler @ 28.04.16, 09:19

Зачем писать имеено функциональный код, или у тебя самоцель чтобы код был функциональный, это код как раз наборот позволяет
стандартизировать систему написанную в стиле ООП, если раньше каждый изобретал свой интерфес ,
то сейчас эти интерфесы станут стандартными, нужен тебе один имплементируй его ,
нужно больше пользуй хоть все 21, мало их расширяй хоть до посинения

Так зачем эти 21 нужны?
Не костыли ли это, случаем?

[settler]

Цитата korvin @ 28.04.16, 16:54

Такое ощущение, что ты просто чего-то от балды нафигачил. Ты же понимаешь, что повторный вызов accept с одним и тем же объектом Person приведёт к повторному добавлению кода к телефону?

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

Где в документации Хасkеля гарантия на защиту при много поточности?, если она есть
то это тоже мутекс, и соотвесвеено те же торомоза, другого еще не придумали,

[Flex Ferrum]

settler, ты, похоже, опять плохо понимаешь, о чём берёшься спорить...

[D_KEY]

Цитата settler @ 28.04.16, 18:15

любой повторный вызов функции изменит стэйт обьеста

При соблюдении функционального стиля этого не будет происходить(или будет происходить редко, в строго ограниченных местах).

Цитата

Где в документации Хасkеля гарантия на защиту при много поточности?, если она есть
то это тоже мутекс, и соотвесвеено те же торомоза, другого еще не придумали,

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

[settler]

Цитата D_KEY @ 28.04.16, 17:28

Так зачем эти 21 нужны?
Не костыли ли это, случаем?

Что был был стандарт, и возможность расширения , включая множесвенное наследование как и по интерфейсу так и по реализации, все знают что для сравнения обьетов есть метод test.На крупных проэктах очень сильно облегчает
проэктирование и поддержку там же сказано
Represents an operation that accepts two input arguments and returns no result,
то есть когда надо два аргумета то вместо велосипеда типа

  public void foo(int x, Person p){
  }

у тебя есть стандартное

 public interface BiConsumer<T,U>

причем выбор у тебя либо реализуй default method в самом интефейсе, либо создавай реализацию в классе,
и классов как ты понимаешь может быть столько сколько надо,
В конце концов не требует твоя задача такой стандартизации - не пользуй,
Ну и к лямдам и фунштионал программинг оно не имеет никакого отношения,

Добавлено 28.04.16, 18:51

Цитата D_KEY @ 28.04.16, 18:27

При соблюдении функционального стиля этого не будет происходить(или будет происходить редко, в строго ограниченных местах).

У меня и в обьектном такого не случалось,

[D_KEY]

Цитата settler @ 28.04.16, 18:49

Цитата D_KEY @ 28.04.16, 18:27

При соблюдении функционального стиля этого не будет происходить(или будет происходить редко, в строго ограниченных местах).

У меня и в обьектном такого не случалось,

У тебя не меняется стейт при повторном вызове? Ну так хорошо. В чем тогда проблема?

Добавлено 28.04.16, 18:58
settler, мне кажется, ты не понимаешь, что тебе пишут

[settler]

Цитата Flex Ferrum @ 28.04.16, 18:22

settler, ты, похоже, опять плохо понимаешь, о чём берёшься спорить...

Возможно 12лет на яве + 5 лет на той самой фунциональщине, хотя и в LS в видимо не достаточно,
Тогда это не называли особым словом,да еще в C# d 2009 эти фичи уже были, но названия также пока не было,
маркетологи его еще не придумали,
Не обратил внимание что на вопрос о частоте применимости ФП пока никто не ответил, ?

Добавлено 28.04.16, 19:18

Цитата D_KEY @ 28.04.16, 18:55

мне кажется, ты не понимаешь, что тебе пишут

Возможно,

[applegame]

Цитата settler @ 28.04.16, 18:15

Где в документации Хасkеля гарантия на защиту при много поточности?, если она есть
то это тоже мутекс, и соотвесвеено те же торомоза, другого еще не придумали,

Зачем синхронизировать иммутабельные сущности? Они же не меняются, от самого рождения до своей смерти в уборщике мусора. Не нужно никакой "защиты от многопоточности".

Сообщение отредактировано: applegame - 28.04.16, 19:23

[Flex Ferrum]

Цитата settler @ 28.04.16, 19:10

Цитата Flex Ferrum @ 28.04.16, 18:22

settler, ты, похоже, опять плохо понимаешь, о чём берёшься спорить...

Возможно 12лет на яве + 5 лет на той самой фунциональщине, хотя и в LS в видимо не достаточно,
Тогда это не называли особым словом,да еще в C# d 2009 эти фичи уже были, но названия также пока не было,
маркетологи его еще не придумали,
Не обратил внимание что на вопрос о частоте применимости ФП пока никто не ответил, ?

Добавлено 28.04.16, 19:18

Цитата D_KEY @ 28.04.16, 18:55

мне кажется, ты не понимаешь, что тебе пишут

Возможно,

Не "возможно", а совершенно определённо.

[Бобёр]

мое мнение о функциональщине - она хороша, но хорошо когда она строго ограниченая, типа LINQ для C#. Что бы по серьёзке использовать Хаскель.. ну... как то не хотелось бы

Сообщение отредактировано: Бобёр - 28.04.16, 20:31

[Flex Ferrum]

Цитата Бобёр @ 28.04.16, 20:31

мое мнение о функциональщине - она хороша, но хорошо когда она строго ограниченая, типа LINQ для C#. Что бы по серьёзке использовать Хаскель.. ну... как то не хотелось бы

Хаскель или F# - это ещё по-божески. У них достаточно programner-friendly синтаксис...