Re[6]: [Ann, c#7] local functions
От: Tesh США  
Дата: 22.05.15 14:43
Оценка: +1 :)
Здравствуйте, IT, Вы писали:

Немерле, как я понял, больше функциональный, чем объекто-ориентированный, поэтому больший уклон в функциональщину там может смотреться вполне логичным.
C# же скорее наоборот.
Что мне не нравится в подобных попытках перенести все возможные фичи в один язык, так это то, что это не способствует единообразию кода между проектами, и получается очередной C++ с многообразием способов прострелить себе ногу.
Как разультат, легко может случиться так, что в проекте, который передадут на развитие, будет человек со своим видением использования тех же локальных функций, что приведет к огромному количеству нечитаемого тяжело поддерживаемого кода.
Отредактировано 22.05.2015 14:45 Tesh . Предыдущая версия .
Re[13]: Nested functions
От: Qbit86 Кипр
Дата: 22.05.15 14:54
Оценка:
Здравствуйте, Tesh, Вы писали:

T>Короткие функции типа лямбд, используемых в linq не требуют именования


А если они вызываются рекурсивно или просто неоднократно? Скажем, используются при декларации отписки от события:
{
    local void HandleSomeEvent(object sender, EventArgs e)
    {
        // Captures some variables from outer scope.
    }
    subject.SomeEvent += HandleSomeEvent;
    _subscriptionDisposables.Add(() => { subject.SomeEvent -= HandleSomeEvent; });
    ...
}


T>а более крупные, объявленные внутри другого метода, только увличат объем этого метода и ухудшат читаемость.


Если выносить вложенные функции в методы того же класса, то они не смогут быть замыканиями; и не смогут гарантировать, что другие методы не начнут вызывать вынесенный, затрудняя его модификацию.
Глаза у меня добрые, но рубашка — смирительная!
Re[14]: Nested functions
От: Tesh США  
Дата: 22.05.15 14:58
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Если выносить вложенные функции в методы того же класса, то они не смогут быть замыканиями; и не смогут гарантировать, что другие методы не начнут вызывать вынесенный, затрудняя его модификацию.


Я бы вообще не использовал события из-за опасности утечки памяти (если забыли отписаться), но если и использовать, то зачем объединять код, обрабатывающий события с кодом, выполняющим подписку?

По поводу вызова обработчкика событий другими методами класса — если класс компактный и состоит из пары-тройки методов, то это не является проблемой.
Отредактировано 22.05.2015 15:00 Tesh . Предыдущая версия .
Re[5]: [Ann, c#7] local functions
От: IT Россия linq2db.com
Дата: 22.05.15 14:59
Оценка:
Здравствуйте, Tesh, Вы писали:

T>А есть более реальный пример, в котором предназначение методов было бы более понятным?


А так идея не понятна? К сожалению, куска из реального проекта не имеется, потому как такие авгиевы конюшни вычищаются в первую очередь.
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: [Ann, c#7] local functions
От: IT Россия linq2db.com
Дата: 22.05.15 15:07
Оценка: +1
Здравствуйте, Tesh, Вы писали:

T>Немерле, как я понял, больше функциональный, чем объекто-ориентированный, поэтому больший уклон в функциональщину там может смотреться вполне логичным.


Немерле как язык — это качественный гибрид, в котором ФП, ООП и МП органично дополняют друг друга.

T>C# же скорее наоборот.


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

T>Как разультат, легко может случиться так, что в проекте, который передадут на развитие, будет человек со своим видением использования тех же локальных функций, что приведет к огромному количеству нечитаемого тяжело поддерживаемого кода.


Эта проблема существует даже на программируемом калькуляторе. У каждого своё видение и способности к производству нечитабельного кода.
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: [Ann, c#7] local functions
От: fddima  
Дата: 22.05.15 15:09
Оценка:
Здравствуйте, Tesh, Вы писали:

T>Немерле, как я понял, больше функциональный, чем объекто-ориентированный, поэтому больший уклон в функциональщину там может смотреться вполне логичным.

T>C# же скорее наоборот.
Скорее наоборот. На уровне деклараций классов / методов — он будет очень похож на C# (что логично). Внутри методов — отличия есть, но в сторону бОльшего удобства. Никто всю функциональщину использовать не заставляет. С Немерле, как с языком, очень легко начать. А вот с F# (для меня лично) — лучше удавиться сразу, потому что — становится совершенно неочевидно, где же там шарп.

T>Что мне не нравится в подобных попытках перенести все возможные фичи в один язык, так это тем, что это не способствует единообразию кода между проектами и получается очередной C++ с многообразием способов прострелить себе ногу.

Всего фич на самом деле не так и много, и в том или ином виде присутствуют или реализуются в других языках. В C++ скорее мешает многословность и мешанина, даже (с моей точки зрения) в очень хорошо структурированных проектах. Кроме того, как писать код — личное дело каждого. Никакого единого стиля не было и не будет, чисто по социальным причинам, и на практике C# код только лишь похож издалека по стилю. Что по факту — вообще никак не мешает — кода или слишком много и за 5 минут его невозможно понять, или код просто хреново написан (на любом языке), или — не хватает знаний, что бы понять код.

T>Как разультат, легко может случиться так, что в проекте, который передадут на развитие, будет человек со своим видением использования тех же локальных функций, что приведет к огромному количеству нечитаемого тяжело поддерживаемого кода.

Не преувеличивайте их значимость. Это всё же простая функция. В яваскрипте таких тонны и этого вообще никого не парит. Не парят они даже тех, кто не понимает что такое замыкание.
А вот ещё у человека может быть ещё и видение всей архитектуры иное (оправданное или нет), или его просто будет раздражать не им написанный код. И как результат — вне зависимости от наличия локальных функций, его передадут ещё раз.
Re[15]: Nested functions
От: Qbit86 Кипр
Дата: 22.05.15 15:13
Оценка: +1
Здравствуйте, Tesh, Вы писали:

T>Я бы вообще не использовал события из-за опасности утечки памяти (если забыли отписаться)


Чтоб не забыть отписаться потом, мы планируем отписку сразу после подписки:
_subscriptionDisposables.Add(/* Unsubscribe */);

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

И как раз из-за невозможности отписки и опасности утечки памяти мы не можем использовать неименованные лямбды:
subject.SomeEvent += (sender, e) => { /* Captures some variables. */ };
subject.SomeEvent -= ???


T>но если и использовать, то зачем объединять код, обрабатывающий события с кодом, выполняющим подписку?


А зачем их разносить, если подписка осуществляется только в одном месте и код обработчика нежелательно вытаскивать наружу?
Глаза у меня добрые, но рубашка — смирительная!
Re[6]: [Ann, c#7] local functions
От: Tesh США  
Дата: 22.05.15 15:30
Оценка:
Здравствуйте, IT, Вы писали:

IT>А так идея не понятна? К сожалению, куска из реального проекта не имеется, потому как такие авгиевы конюшни вычищаются в первую очередь.


Так не понятно, можно ли этот класс декомпозировать или нет.
Re[16]: Nested functions
От: Tesh США  
Дата: 22.05.15 15:37
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>А зачем их разносить, если подписка осуществляется только в одном месте и код обработчика нежелательно вытаскивать наружу?


Почему нежелательно? Вообще зависит от того на что и где подписываетесь. Если сам объект, генерирующий события, живет только в пределах одного метода, и логика обработки события предельно проста, то можно и обычные лямбды использовать.
Если же объект живет в пределах класса, либо логика обработки события более сложная, то по-моему такой обработчик нужно выносить в отдельный метод.

Если бы был какой-то реальный пример, то можно было бы более предметно обсуждать.
Re[3]: [Ann, c#7] local functions
От: IT Россия linq2db.com
Дата: 22.05.15 15:40
Оценка: 40 (4) +3
Здравствуйте, Sinix, Вы писали:

VD>>Практика показала, что локальные функции помогает очистить и структурировать код. Так что мимо.

S>Без обид, но нет. Скорее, получается копипаста и дублирование кода из-за того, что никто не знает, что подобный код уже написан.

Без обид, но да. Копипаста и дублирование — это когда копипаста и дублирование десятков и сотен строк кода. Копипаста 5-ти строчек кода — это не копипаста. Естественно, никто локальные фукнции в сотню строк кода писать не собирается. А вот для 5-ти строк — самое оно. Что получается при вынесении такого кода в приватный хелпер я тут уже демонстрировал.

Что касается ентерпрайзов, то лично для меня качественно реализованная бизнес логика — это прежде всего качественно изолированная бизнес логика от другой бизнес логики. Под этим следует понимать не всякие слои и прочие дробящие логику техники, а подход "вся логика в одном флаконе". Критерий качества очень простой — чем проще функциональный кусок извлекается из места дислокации без болезненных ощущений и оставшихся рудиментов, тем качество такого кода выше. Не трудно сообразить, что локальные функции при таком подходе всячески способствуют увеличению качества кода.

При работе на Немерле неоднократно наблюдалась (не только у меня одного) такая метаморфоза. Наплевав на догмы про размер метода, определённый функционал реализовывался внутри одного метода с широким использованием локальных фукнций. При достижении определённого, естественно субъективного, уровня дискомфорта, это метод вжик — и лёгким движением руки превращался в класс, где локальные функции становились приватными методами, а контекст метода распределялся по классу. В дальнейшем с одним из методов этого нового класса вполне могла произойти очередная подобная метаморфоза. Т.е. локальные функции при развитии функционала позволяют удерживать его вместе, а не дробить, что в дальнейшем способствует простоте преобразования такого функционала в более крупные компоненты.

Ну а грохнуть ненужный код без оставления рудиментов — так тут вообще много ума не надо.
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: [Ann, c#7] local functions
От: Tesh США  
Дата: 22.05.15 15:42
Оценка:
Здравствуйте, fddima, Вы писали:

T>>Что мне не нравится в подобных попытках перенести все возможные фичи в один язык, так это тем, что это не способствует единообразию кода между проектами и получается очередной C++ с многообразием способов прострелить себе ногу.

F> Кроме того, как писать код — личное дело каждого.
Я бы так не сказал, есть команда и внутри команды стиль написания и оформления кода должен быть предельно единым.

F>Никакого единого стиля не было и не будет, чисто по социальным причинам, и на практике C# код только лишь похож издалека по стилю. Что по факту — вообще никак не мешает — кода или слишком много и за 5 минут его невозможно понять, или код просто хреново написан (на любом языке), или — не хватает знаний, что бы понять код.


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

F> Не преувеличивайте их значимость. Это всё же простая функция. В яваскрипте таких тонны и этого вообще никого не парит. Не парят они даже тех, кто не понимает что такое замыкание.

F> А вот ещё у человека может быть ещё и видение всей архитектуры иное (оправданное или нет), или его просто будет раздражать не им написанный код. И как результат — вне зависимости от наличия локальных функций, его передадут ещё раз.

Сам факт возможности объявления полноценного метода внутри другого метода у меня не вызывает положительных эмоций.
Re[8]: [Ann, c#7] local functions
От: Tesh США  
Дата: 22.05.15 15:44
Оценка: +1
Здравствуйте, IT, Вы писали:

IT>Эта проблема существует даже на программируемом калькуляторе. У каждого своё видение и способности к производству нечитабельного кода.


Вопрос в том насколько язык ограничивает, либо способствует написанию такого кода. Иначе можно возвести в абсолют: наводнить язык всевозможным количеством фич, защищая это тем, что спагетти код и без них может быть написан.
Как результат, время вхождения в проект только увеличится.
Re[9]: [Ann, c#7] local functions
От: fddima  
Дата: 22.05.15 16:10
Оценка: +1
Здравствуйте, Tesh, Вы писали:

F>> Кроме того, как писать код — личное дело каждого.

T>Я бы так не сказал, есть команда и внутри команды стиль написания и оформления кода должен быть предельно единым.
Тем не менее у каждой команды — свой отличимый от других стиль. Консистентность стиля внутри проекта/команды — это уже другой вопрос организации внутри команды.

F>>Никакого единого стиля не было и не будет, чисто по социальным причинам, и на практике C# код только лишь похож издалека по стилю. Что по факту — вообще никак не мешает — кода или слишком много и за 5 минут его невозможно понять, или код просто хреново написан (на любом языке), или — не хватает знаний, что бы понять код.

T>Если говорить о разных проектах, то чем более строг язык, тем меньше вариантов реализации похожих вещей, а значит тем легче вхождение в новый проект.
T>Если код за 5 минут невозможно понять, то в общем случае он не должен пройти ревью и должен быть переписан.
Задачи не ограничиваются только лишь написанием кода, но и багофиксинга. В период идентификации проблем, нужно "лазить" не только по коду своего проекта, но возможно и коллег, а иногда даже и по коду используемых библиотек или нижележащей платформы. Так вот во всём, с чем, вы лично не сталкивались — за 5 минут, как правило, мало что можно выяснить, и в общем случае — их код не может быть переписан (даже если вдруг и нужен фикс). А быстрота вхождения будет зависеть не сколько от языка и его фич, а сколько от знакомства с проблемой которую код решает. В этом плане, вдобавок, локальные функции будут сильно выигрывать, т.к. код и локализован и именован.

F>> Не преувеличивайте их значимость. Это всё же простая функция. В яваскрипте таких тонны и этого вообще никого не парит. Не парят они даже тех, кто не понимает что такое замыкание.

F>> А вот ещё у человека может быть ещё и видение всей архитектуры иное (оправданное или нет), или его просто будет раздражать не им написанный код. И как результат — вне зависимости от наличия локальных функций, его передадут ещё раз.
T>Сам факт возможности объявления полноценного метода внутри другого метода у меня не вызывает положительных эмоций.
И тем не менее — есть очень положительная практика среди других популярных языков.
Re[7]: [Ann, c#7] local functions
От: IT Россия linq2db.com
Дата: 22.05.15 16:32
Оценка:
Здравствуйте, Tesh, Вы писали:

IT>>А так идея не понятна? К сожалению, куска из реального проекта не имеется, потому как такие авгиевы конюшни вычищаются в первую очередь.

T>Так не понятно, можно ли этот класс декомпозировать или нет.

А это тут каким боком?
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: [Ann, c#7] local functions
От: fddima  
Дата: 22.05.15 16:42
Оценка: +1
Здравствуйте, Tesh, Вы писали:

T>Вопрос в том насколько язык ограничивает, либо способствует написанию такого кода. Иначе можно возвести в абсолют: наводнить язык всевозможным количеством фич, защищая это тем, что спагетти код и без них может быть написан.

T>Как результат, время вхождения в проект только увеличится.
Я уже сказал, что время вхождения — зависит от опыта вообще и знакомства с предметом. Ну базовое знание языка как бы подразумевается и так.
А "спагетти" и так можно написать на любом языке. На C# и Java — например, делегаты, лямбды есть в языке. В C++ — их нет (новые C++ пока оставляем в стороне, это просто пример, а не C# vs C++). При этом в C++ делегаты разумеется используются в полный рост, тем или иным способом — в итоге код получается где-то более шумным, а между библиотеками — они разные (несовместимые). Ну и где же тут преимущество в ограничении нас в использовании фич?
Наоборот — чем больше возможностей есть — тем лучше (ещё круче, когда есть легальный способ расширения комплиятора). Тогда программисты имеют шанс воспользоваться стандартными средствами для решения своих задач.

Всё таки в контексте локальных функций — это вообще смешно звучит. Я вообще не встречал людей, у которых бы были с ними проблемы в JavaScript. А на фоне всех фич C# — эта (в плане использования / понятности) — вообще выглядит мелочью.
Re[9]: [Ann, c#7] local functions
От: IT Россия linq2db.com
Дата: 22.05.15 16:57
Оценка:
Здравствуйте, Tesh, Вы писали:

T>Вопрос в том насколько язык ограничивает, либо способствует написанию такого кода.


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

T>Иначе можно возвести в абсолют: наводнить язык всевозможным количеством фич, защищая это тем, что спагетти код и без них может быть написан.


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

T>Как результат, время вхождения в проект только увеличится.


Это старая песня закалённого в интригах менеджера про пучок индусов вместо одного вменяемого разработчика. Тут есть только одна проблема — функция Sum для IQ не работает. Работает только функция Max. Тренеруйте своих разработчиков, гоните в шею бездарей и всё у вас получится. Посредственности могут выдавать только посредственный результат.
Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: Tail call elimination
От: Evgeny.Panasyuk Россия  
Дата: 22.05.15 17:10
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Быструю сортировку можно и без рекурсивных вызовов организовать, эмулировав стек, но так обычно не делают в стандартных библиотеках. То есть почему-то не спешат менять потенциальный StackOverflowEcxeption на потениальный OutOfMemoryException. Добавляют при необходимоти guard глубины рекурсии, и живут себе, поди, без штрафов к премиям.


Справедливости ради, в нормальной quicksort глубина стэка гарантированно ограничена O(ln(N)), в worst case.
Там внутри две рекурсии — по левой стороне массива и по правой. Для той у которой размер массива больше — делают ручной tail call. То есть рекурсия происходит всегда в меньшую сторону, причём это может быть как левая, так и правая сторона.
Размер меньшей части гарантированно меньше половины размера исходного массива, то есть рекурсия как минимум делится пополам, что гарантирует логарифмическую глубину.

Ограничение глубины рекурсии (причём не "реальной" глубины, а чисто алгоритмической, то есть без учёта tail call) — делается с целью перехода на алгоритм сортировки с гарантированной сложностью O(N*ln(N)) — чтобы получить общую сложность алгоритма O(N*ln(N)) в worst case.
Так, например, introsort сначала использует quicksort (потому что очень быстрая и cache-friendly), потом если глубина превышает заданный порог то делается heapsort (потому что гарантированно O(N*ln(N))), а потом ещё в некоторых вариантах когда размер всех под-масивов мал — выполняется финальное расчёсывание через insertion sort — так например во многих реализациях STL.

P.S. А вообще, на x64 проблема с переполнением стэка от рекурсии менее актуальна — достаточно зарезервировать побольше адресов под стэк.
Re[10]: [Ann, c#7] local functions
От: Sinix  
Дата: 22.05.15 17:18
Оценка:
Здравствуйте, IT, Вы писали:


IT>Это старая песня закалённого в интригах менеджера про пучок индусов вместо одного вменяемого разработчика. Тут есть только одна проблема — функция Sum для IQ не работает. Работает только функция Max.

Скорее, Max-Stdev. Ибо ещё и разгребать за остальными
Re[8]: [Ann, c#7] local functions
От: Tesh США  
Дата: 22.05.15 17:56
Оценка: :)
Здравствуйте, IT, Вы писали:

IT>А это тут каким боком?


Таким, что проблема, возможно, в другом и решается архитектурно.
Re: [Ann, c#7] local functions
От: koandrew Канада http://thingselectronic.blogspot.ca/
Дата: 22.05.15 17:58
Оценка: +4
Здравствуйте, Sinix, Вы писали:

S><skipped>


Я кстати в плюсовом коде активно применяю лямбды в качестве локальных функций, и компилятор там, в отличие от .NET, не страдает формализмом головного мозга, а тупо инлайнит лямбды (как ИМХО и положено вести себя хорошему компилятору).
[КУ] оккупировала армия.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.