> Давай, покажи мне, как сделать простой pattern matching на жабе.

жаба была сделана санками для завоевания Мирового (R) Господства (ТМ), но в результате потянула их на дно

на яве много чего нет — и это не делает скалу хорошей

х=10, а где проблема?

Короче как там говорят проблема не только с имплементацией но и со спецификацией логичной модели

че-то похоже да, у одерского нет хорошей модели ооп

> Предложи лучший вариант с учетом того, что он должен работать на JVM и быть совместимым с существующим Java-кодом.

если мы вводим еще один способ проверки программ на вшивость, например, контролируя нулл, то мы не сможем «быть совместимым с существующим Java-кодом», пока 1. не проаннотируем по-новому и 2. не прочекаем на аннотации этот существующий код

т.е. фактически надо конвертнуть код на новый язык

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

>х=10, а где проблема?

Как где проблема!

Здесь вам не тут, в смысле не Cи с крестами.

val a:A = B(5)

print(a.x) - чему равен x?

А в паттерн матчинге

B(5) match {
case B(x) => что тут 5
....
case A(x) => а тут 10?
}

И в случае case B(x) - как это 5 вообще получить? x / 2 чтоле?:) Там при передаче в предка может быть любое выражение - обратное от него не построить.

Да и кому нужно это 10 - ведь основная задача кейс классов - это реализация алгебраических типов - кому такие бардачно-странные алгебрические типы нужны когда конструктор B(5), а внутреннее состояние почему-то 10. и при матчинге - 10. Это ж тихий ужос.

>Мой код приводит к точно таким же изменениям.

Твой код с сайдэффектами - это класс ..Handler. У меня такого не было.

Еще раз. Сайд-эффекты в обоих вариантах производят две конструкции: a) обращение к respond и b) 'request.session(«user») = user'. Только вы их вызываете напрямую в login, у меня это перенесено в методы Handler-а. Сам же Handler является иммутабельным объектом, собственное состояние которого не меняется.

Т.о. сайд-эффекты есть в обоих вариантах. И ваша претензция по поводу появления сайд-эффектов все еще требует обоснования, либо снятия.

Ну вот я смотрю - вроде класс хендлера то что надо - да не работает.

Ключевое слово «вроде». В моем коде нет повторноиспользуемых компонентов, их еще нужно сделать. Когда сделаете — это будет уже ваш код. И «вроде» вы будете уже выискивать среди своих багов.

Я вызываю 4 разных метода handle* и он делает что попало. Передал схему автентикации петровка - вызвал handleUsusal - попал на сенситивную инфу. Куда не кинь всюду клин. 5 методов, звать можно как угодно, в какой угодно последовательности

Берем пример кода на Scala, который иллюстрирует мой подход:

package test;

class TopLevel
{
    def login(login: String, password: String)
    {
        (new LoginHandler(login, password)).handle();
        (new LoginHandler(login, password)).handleCaseOne(); /* line 8 */
    }

    private class LoginHandler(login: String, password: String)
    {
        def handle()   
        {
            handleCaseOne();
            handleCaseTwo();
        }

        private def handleCaseOne()
        {}

        private def handleCaseTwo()
        {}
    }
}

TopLevel.scala:8: error: method handleCaseOne cannot be accessed in TopLevel.this.LoginHandler
        (new LoginHandler(login, password)).handleCaseOne();

В случае с Java да, согласен, я забыл про Java-правила видимости. Но в Java если сделать так:

package test;

public class TopLevel
{
	public void login(String login, String password)
	{
		(new LoginHandler(login, password)).handle();
		(new LoginHandler(login, password)).handleCaseOne();
	}

	private class LoginHandler
	{
		private String login;
		private String password;

		LoginHandler(String login, String password)
		{
			this.login = login;
			this.password = password;
		}

		public void handle()
		{
			handleCaseOne();
			handleCaseTwo();
		}

		private void handleCaseOne()
		{}

		private void handleCaseTwo()
		{}
	}
}

package test;

public class AnotherLogginer
{
	public void login(String login, String password)
	{
		(new TopLevel.LoginHandler(login, password)).handle();
	}
}

AnotherLogginer.java:7: test.TopLevel.LoginHandler has private access in test.TopLevel
                (new TopLevel.LoginHandler(login, password)).handle();

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

А публичность интерфейса как определяется?

Я на нормальном языке программирую, там что в публичный hpp-файл поместили, то и интерфейс :)

> если мы вводим еще один способ проверки программ на вшивость, например, контролируя нулл, то мы не сможем «быть совместимым с существующим Java-кодом», пока 1. не проаннотируем по-новому и 2. не прочекаем на аннотации этот существующий код

т.е. фактически надо конвертнуть код на новый язык

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

Ты вроде неглупый человек, а развёл тут демагогию и юношеский максимализм.

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

Да и вообще ты эту проблему с неполным матчингом нуллов высосал из пальца, потому что никто в здравом уме нуллы в матчинг не передаёт.

В своем нижеследующем коде, вводя внутренний класс LoginHandler, ты просто изобретаешь то, что компилятор Scala делает автоматически при создании замыкания, иначе говоря, функции. Явный антипаттерн Ф.П. (хотя у меня сильная аллергия на слово «паттерн»). В сообщении из твоего блога есть похожий класс KnownUserLoginHandler. На мой взгляд там должна была создаваться функция (не метод и не класс), если уж так хочется лишить логику обработки прекрасного свойства локальности.

package test;

class TopLevel
{
    def login(login: String, password: String)
    {
        (new LoginHandler(login, password)).handle();
        (new LoginHandler(login, password)).handleCaseOne(); /* line 8 */
    }

    private class LoginHandler(login: String, password: String)
    {
        def handle()   
        {
            handleCaseOne();
            handleCaseTwo();
        }

        private def handleCaseOne()
        {}

        private def handleCaseTwo()
        {}
    }
}

А если функция создается только для того, чтобы тут же ее запустить, то нафиг это не надо.

На мой взгляд там должна была создаваться функция (не метод и не класс)

Я на Scala с 2007-го ничего не писал вообще. Поэтому про локальные функци забыл.

Тем не менее, при желании класс Handler можно выцепить и обложить отдельными тестами. В случае локальных функций такое сделать будет сложнее.

Армстронг, правда, так же грамотно опустил scala actors

Армстронг, правда, так же грамотно опустил scala actors

ссылку на почитать и предметно обсудить скинешь?

>И ваша претензция по поводу появления сайд-эффектов все еще требует обоснования, либо снятия.

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

Ключевое слово «вроде».

Изложи функциональность класса Handler.

Когда сделаете — это будет уже ваш код. И «вроде» вы будете уже выискивать среди своих багов.

То есть ты написал говно - а разгребать его должен я? Ахренеть!

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

Т.е. ваши аргументы касательно приватных методов в приватном классе в Scala не работают.

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

Если вы попробуете сконструировать объект LoginHandler в другом классе:

Потому я и сказал что я пишу еще один метод в этом же классе. И вот я его пишу....

Следовательно, разговоры о том, что когда-нибудь кто-нибудь, обратиться не к том методу Handler — это из области праздных разговоров.

Топлевел это класс который вызывает майн, все что вызывается из майна - внутренности проекта, следовательно 2ГБ исходников которые работают путем вызова из майна можно писать как курица лапой - все должны знать назубок и делать все правильно потому что надо делать все правильно - я правильно понял суть твоего аргумента?

Я на нормальном языке программирую, там что в публичный hpp-файл поместили, то и интерфейс :)

А я на окамле могу програмку написать - все что в сигнатуре модуля обїявлено - то и интерфейс. И что?

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

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

Нет, описание в википедии меня не интересуют. Мне интересно, что вы считаете сайд-эффектом и почему.

Изложи функциональность класса Handler.

Короче, чем это сделано в исходно коде не получится.

То есть ты написал говно - а разгребать его должен я? Ахренеть!

Я написал код для себя. Без намека на повторное использование. Вы его решили переиспользовать. Несите ответственность за свое решение самостоятельно. BTW, вашу реализацию login можно вообще только скопипастить :)

Ты ж тут все рафкторил в жабу и говорил какая гадость ненужнае скала и как крута жаба - а теперь будешь скалой козырять?

Внимательный вы мой, прочитайте сначала то, что я написал. Первый вариант был на Scala, второй на Java. Получившиеся варианты очень похожи.

И вывод мой был простой — Scala не настолько крута, чтобы обычные Java-разработчики на нее ломанулись толпой.

Однако, слов сказано много. Толку, т.е. объяснения, почему в моем коде есть сайд-эффекты, а в вашем нет, я не увидел. Есть у меня такая возможность?

>. Мне интересно, что вы считаете сайд-эффектом и почему.

http://en.wikipedia.org/wiki/Side_effect_(computer_science)

Короче, чем это сделано в исходно коде не получится.

Это такое описание фукнкциональности класса O_o?

Я написал код для себя. Без намека на повторное использование.

Шикарно вы там пишете проекты! Это просто великолепно!

BTW, вашу реализацию login можно вообще только скопипастить :)

Наверное широко применяемый у вас метод - ведь все для себя и одноразовое.

Внимательный вы мой, прочитайте сначала то, что я написал

Я читаю.

Чтобы получилось так, как привык писать я сам. И как я требую поступать от своих подчиненных.

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

Я написал код для себя. Без намека на повторное использование.

В моем коде нет повторноиспользуемых компонентов,

если метод что-то меняет…то его название должно начинаться с глагола.

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

Раз тесты не проходят, значит… руки не оттуда растут. //тестируемый код чужой

Ши-зо-фре-ния.

Твой код в блоге - это феерический ужас. Его можно разнести и по фаулеру, и по банде четырех, и по чем угодно.

Ты не ответил на вопрос (вообще-то на кучу самых интересных вопросов) - все что в особенностях реализации у вас может быть каким-угодно говном? Потому что это прямо проистекает из твоих утверждений.

>Толку, т.е. объяснения, почему в моем коде есть сайд-эффекты, а в вашем нет, я не увидел. Есть у меня такая возможность?

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

Как только напишешь корректный код который не позволит вызвать неверныё методы на неверном наборе параметров. И сразу тебе станет ясно.[/qoute]

Т.е. объяснить вы ничего не можете.

Почитай архитектор. Это то чем пестрит твой мегарефакторинг:

http://en.wikipedia.org/wiki/Anemic_Domain_Model
http://en.wikipedia.org/wiki/Circular_dependency
http://en.wikipedia.org/wiki/Object_cesspool
http://en.wikipedia.org/wiki/Object_orgy
http://en.wikipedia.org/wiki/Sequential_coupling
http://en.wikipedia.org/wiki/Yo-yo_problem
http://en.wikipedia.org/wiki/Accidental_complexity
http://en.wikipedia.org/wiki/Spaghetti_code
http://en.wikipedia.org/wiki/Improbability_factor

Ну и на последок вот:
http://en.wikipedia.org/wiki/Cargo_cult_programming

>Т.е. объяснить вы ничего не можете.

Я это объяснил там где привел этот список. Ты не понял. Сделай то что я говорю - и ты увидишь.

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

Вы заявили, что в моем коде есть сайд-эффекты, тогда как в вашем их нет. Бремя доказательства лежит на том, кто утверждение сделал.

Пожалуста, приведите свое определение сайд-эффекта и покажите, почему в моем коде они присуствуют, а в вашем нет. Ссылки приводить не нужно, поскольку очевидно, что читая один и тот же текст мы видим разные вещи.

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

пфп6, стр 10-11

>Вы заявили, что в моем коде есть сайд-эффекты, тогда как в вашем их нет. Бремя доказательства лежит на том, кто утверждение сделал.

Как только будет семантически эквивалентный код.

Пожалуста, приведите свое определение сайд-эффекта и покажите, почему в моем коде они присуствуют, а в вашем нет.

Мое определение в википедии. Сайд эффект который у меня не присутствует есть в твоем классе с состоянием.

>Просто попробуйте доказать ваш тезис.

К стати я так понимаю по поводу остальных параметров изложенных в таблице, а также списка присутствующих в коде антипаттернов претензий нет?

>Вы заявили, что в моем коде есть сайд-эффекты, тогда как в вашем их нет. Бремя доказательства лежит на том, кто утверждение сделал.

Как только будет семантически эквивалентный код.

Вы видели код, сделали свое утверждение. Теперь требуете еще что-то.

Либо доказывайте, либо забирайте назад.

Мое определение в википедии.

Википедия говорит о том, что в результате вычисления изменяется «состояние мира». У вас оно изменяется хотя бы вот здесь:

request.session("user") = user

Runtime.getRuntime.exec(scheme.command.replace("{login}", login).replace("{password}", password))

respond(UNAUTHORIZED, "User not found")

Так что вы явно противоречите определению на которое ссылайтесь. Дайте же свое определение, которому ваш код будет соответствовать.

Сайд эффект который у меня не присутствует есть в твоем классе с состоянием.

С иммутабельным состоянием. И объекты этого класса являются временными, они уничтожаются после завершения «вычислений», сам факт их существования ни на чем не отражается.

Так что попробуйте еще раз.

К стати я так понимаю по поводу остальных параметров изложенных в таблице, а также списка присутствующих в коде антипаттернов претензий нет?

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

>Либо доказывайте, либо забирайте назад.

А может еще 3 километра пробежать?

request.session(«user») = user

Изменится. Я про это уже говорил. Единственное место.

Runtime.getRuntime.exec

Не изменится.

respond(UNAUTHORIZED, «User not found»)

Не изменится.

С иммутабельным состоянием.

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

И объекты этого класса являются временными, они уничтожаются после завершения «вычислений», сам факт их существования ни на чем не отражается.

Когда я запускал текстовый редактор катя - после завершения «вычислений» все объекты уничтождились, и сам факт их существования не на чем не отраззился. Наверное весь код редактора кати - без сайд эффектов. А сейчас я пойду домой и выключу комп - погаснет вся операционка, и ее существование ни на чем не отразится во внешнем мире. Наверное фоннеймановская архитектура сплош состоит и блоков которые являются чистыми функциями.

>Не правильно.

Доказывай какой из них неправильный.

>Не правильно.

Доказывай какой из них неправильный.

Я не делал никаких утверждений о правильности/неправильности, т.к. ваши требования мимо кассы. Истрия вопроса:

К стати я так понимаю по поводу остальных параметров изложенных в таблице, а также списка присутствующих в коде антипаттернов претензий нет?

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

Не правильно вы понимаете. Претезии есть.

> request.session(«user») = user

Изменится. Я про это уже говорил. Единственное место.

Т.е. сайд-эффект все-таки есть. Или «один раз не пидорас»?

>Я не делал никаких утверждений о правильности/неправильности

Кто это написал?

Не правильно.

Не правильно вы понимаете.

Доказывай что неправильно.

> Или «один раз не пидорас»?

Не надо свой опыт (после чего ты так код начал писать наверное) переносить на других.

вот такая эмуляция where

пришлось раставить ретурны и один тупняк, однако по-моему прилично похоже на where

кстати компилиться

object HelloWorld {
    def main(args: Array[String]) {
        println( login("user","pw") )
    }

    def login(username: String, password: String): Response = {
        if( username == null || password == null )
            return respond( UNAUTHORIZED, "You should provide login and password" )
        else
            println("some code here")
            println("some code here")
            println("some code here")
            return oldStyleLogin

        def oldStyleLogin = {
            println("checking username="+username+" password="+password)
            uncheckedLogin
        }
        def uncheckedLogin = {
            println("uncheckedLogin username="+username+" password="+password)
            respond( AUTHORIZED, "ok" )
        }
        return respond(UNAUTHORIZED, "something was wrong") /// compiler_please_shut_up
    }
    val UNAUTHORIZED=400; val AUTHORIZED=200
    type Response = String
    def respond(i: int, message: String): Response = {
        return ""+i+" "+message
    }
}

а что если твой пример переписать вот так: http://www.linux.org.ru/jump-message.jsp?msgid=5817442&cid=5834052

вообще скала, когда я пробовал на ней писать, производила впечатление недоработанной напильником

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

Эх, в интернете кто-то неправ...

Гражданин r. Разрешите изложить несколько тезисов, которые, как мне кажется, очевидны любому, кто следит за дискуссией:

1. Вы рассматриваете свой код как «вещь в себе», а код eao197 как претендующий на повторное использование и считаете это нормальным. Между тем, рефакторинг eao197 был предназначен не для реального проекта, и не для повторного использования, а только для иллюстрации того, что ваш код написан, с его точки зрения, плохо (с моей, в общем-то, тоже).

2. В вашем коде имеется побочный эффект. Зачем отрицать очевидное. Для пользователя оба варианта чистыми не являются. (И что это за метрики, показавшие отсутствие побочных эффектов? :) )

3. Внутренний класс для внешнего наблюдателя не является побочным эффектом, так же, как переменная в функции или замыкание. Функция Main на 2 гигабайта - ну что же, довести до абсурда можно что угодно. Где-то пролегает разумная граница, ниже которой соблюдать все инварианты не следует, можете, например, у Макконнелла почитать (раздел 8.5 «Изоляция повреждений, вызванных ошибками»).

4. Чисто личное впечатление: ваш код - сваленное в кучу нагромождение операторов. С моей точки зрения, читать его трудно. Хотя люди разные, кому-то и код на J читать легко...

P.S. Ваша хамская манера вести дискуссию вызывает неприязнь.

P.P.S. Я не клон eao197. :) Выражаю ему респект за сдержанность.

1. Я рассматриваю оба кода совершенно одинаково. «Вещь в себе» мой код по причине того что он состоит из одной функции - это его физическая сущьность. eao197 ввел в обращение множество методов и еще один класс. Эти сущьности сразу же попадают под все параметры оценки их качества - как и любые другие методы и классы включая мой.

Я смотрю на них объективно со стороны, я, как код ревьювер беру отдельный, класс ....Handler и пишу его обективные характеристики:

1. он использует метод respond обявленный в outer scope, в то время как outer scope использует его - это cyclic dependency - антипаттерн.

2. в жабской версии его методы handle видимы аутерскоупу, следовательно они для аутерскоупа - публичный интерфейс. В аутерскоупе можно создать инстанс этого класса и вызывать любые его методы в любом порядке. Это приводит к очевидно неправильному поведению. Клас который может работать неправильно через свой публично-доступный интерфейс спроектирован плохо. Это приводит к object cesspool и object orgy.

3. В классе ....Handler, всего один публичный метод и 4 приватных. Этот класс не должен быть классом в принципе - он должен быть заменен статическим методом. Класс с одним методом - антипаттерн.

4. 80% приватных методов в классе обозначает то что класс занимается не своим делом - содержит некую неабстрагированную логику которую надо вынести в другой класс для которого это будет его прямая функция и публичный интерфейс. Это прямо облегчит тестирование и реюс кода. Здесь это не так - класс спроектирован плохо.

5. eoa157 утверждает что чтобы пользоваться этим классом правильно надо разбиратья во внутренностях и звать методы правильно - а именно только метод handle. Это антипаттерн - называется sequential coupling. В дополнение того что нужно знать всю логику всего кода включая аутер скоуп досконально чтобы пользоваться классом хендлер - это типичная пролема yo-yo.

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

7. Методы типа handleUsual/handle(чего там через петровку) позволяют осуществить попытку автентикации через системы которые запрещены параметрами пользователя. Это значит что методы не проверяют корректность своих параметров (маскировка этих параметров полями ничего не меняет - это входные данные для методов). Значит не осуществляется защита инвариантов. Методы написаны плохо - они не проверяют собственные параметры. Если вам хотелось объектно помедитировать - то в этом случае типичный паттерн стратегия/абстрактная фабрика анамнез для которой наличие if/switch - который там работает по селектору authSceme.

8. Ответы оппонента на мои вопросы относительно потенциального мисюса вида «разбираться надо во внутренностях перед тем как пользоваться» - это accidental complexity. Он породил слоности там где их не было и не должно было быть а породив эти сложности еще и не защитился от неправильного использования которое позволет его код как я указал выше.

9. Его предложенный код является каноническим образцом спагетти - из его 25 строк которые оцениваются общепринятыми метриками как функциональный код - 9 являются переходами - 36% его кода - это просто JUMPS. А во всем коде его физическая рабочая часть - это 27% в скале и 16% в джаве. Если бы это было обявление функционального сложного публичного интерфейса - это не было бы так страшно, но поскольку оппонент сам настаивает что это все не является интерфейсом ни в каком виде - это обознаяает что 84% его кода - визуальный мусор который ничего не делает. Своими «канцелярскими методами» он просто заменил программу вида:

def f(a,b,c,d) = a + b - c / d

на програму вида:

def f1(a,b) = a + b
def f2(a,b) = a - b
def f3(a,b) = a / b
def f(a,b,c,d) = {
var x = f1(a,b)
x = f2(x,c)
x = f3(x,d)
return x
}

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

Продолжать можно долго. Это был ответ на пункт 1.

Функция Main на 2 гигабайта - ну что же, довести до абсурда можно что угодно

Здесь код в 93 строки с 2мя классами и дюжтиной методов. Изщвините меня. Может доведем до абсурда количество методов или классов на которые не распространяются правила грамотного проектирования и можно писать всякое гавно?

Выражаю ему респект за сдержанность.

Серьезно? Ну пойдите почитайте вступление в блоге. Там он герой по и употребляет выражения вроде вброс говна в вентилятор и говнокод на каждом шагу.

Кто этого всего не понимает - банда четырех и фаулер - до просветления.

что, стоит учить скалу? денег от этого у меня прибавиться?

Вы во многом правы, но время зря тратите.

Питекантроп за меня ответил:)

твой кусок кода спровоцировал очень интересную дискуссию

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

1. потеряна инфа, *несомненно* существовавшая на этапе проектирования сверху-вниз

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

оставить ее в виде названий функций, как предлагает еао197, это как минимум канцелярит, и плохо поддерживается скалой

2. не выделена в функцию функция uncheckedLogin

она использована 2 раза, и по моему опыту это *уже* источник багов

(кроме того, около нее должна быть написана дока, что значит быть залогиненым, но хрен с ними, с доками — изначально шла речь о коде)

вопрос «в локальную или глобальную» не совсем ясен; вполне возможно, на боевой системе надо иметь в запасе возможность залогинить кого угодно безо всяких консультаций с базой, написания командно-строчных врапперов и правки конфигов; еще и с целью тестирования имеет смысл ее сделать глобальной

да, забыл написать — из оправданий по п.1 есть то, что потерянная инфа довольно быстро восстанавливается по коду человеком в теме, но это довольно слабое оправдание

> что, стоит учить скалу? денег от этого у меня прибавиться?

думаю что тебе — не стоит

если бы вопрос стоял «смогу ли я на скале писать так, как считаю правильным», то возможно да

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

а вот вопрос без сарказм: скала скорее для личных проектов или же для работы в ынтерпрайзе?

>потеряна инфа, *несомненно* существовавшая на этапе проектирования сверху-вниз

Какая конкретно инфа потеряна? По меоему все легко поняли что делает код.

Напиши мой код с комментариями.

не выделена в функцию функция uncheckedLogin

которая все что делает - это кладет юзера в сессию?

что есть позитивная разница между

session(«user») = user

uncheckedLogin(session, user) ?

с реализацией

def uncheckedLogin(session, user) {
session(«user») = user
}

То есть это буквально положить значение по ключу в мапу.

кроме того, около нее должна быть написана дока, что значит быть залогиненым, но хрен с ними, с доками — изначально шла речь о коде)

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

В жабе было бы написано

session.setAttribute(«user», user);

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

Из того что написал еао197 человек вообще будет очень долго дедуктировать что оно делает и как должно работать.

>скала скорее для личных проектов или же для работы в ынтерпрайзе?

У меня она в тырпрайзе.

шикарный образцовый разнос. thanx.

правда его можно было сделать еще страницы 3-4 назад :)

Вопрос. Сегодя вот писал код работающий с либой jsch. Вот код конфигурирования либы:

       session = jsch.getSession....
       session.setConfig("StrictHostKeyChecking", "no");
       session.setConfig("PreferredAuthentications", "publickey");
       session.connect

По твоему его тоже надо было заменить на:

       session = jsch.getSession....
       disableStricHostCkeching(session)
       setPublicKeyAsPrefferedAuth(session)
       session.connect

def disableStricHostCkeching(session) {
       session.setConfig("StrictHostKeyChecking", "no");
}

def setPublicKeyAsPrefferedAuth(session) {
       session.setConfig("PreferredAuthentications", "publickey");
}

А вот код параметризации встроенного веб сервера:

       private val httpParams = new BasicHttpParams()
        locally {
                httpParams.setIntParameter( CoreConnectionPNames.SO_TIMEOUT, 5000 )
                httpParams.setIntParameter( CoreConnectionPNames.SOCKET_BUFFER_SIZE, 8 * 1024 )
                httpParams.setBooleanParameter( CoreConnectionPNames.STALE_CONNECTION_CHECK, false )
                httpParams.setBooleanParameter( CoreConnectionPNames.TCP_NODELAY, true )
                httpParams.setParameter( CoreProtocolPNames.ORIGIN_SERVER, "Butter4sREST/1.0" )
        }
        private val registry = new HttpRequestHandlerRegistry();
        private val processor = new BasicHttpProcessor()
        locally {
                processor.addInterceptor( new ResponseDate() )
                processor.addInterceptor( new ResponseServer() )
                processor.addInterceptor( new ResponseContent() )
                processor.addInterceptor( new ResponseConnControl() )
        }

тут что тоже надо было сделать 9 «комментирующих» однострочников?

Это ж ужос.

>правда его можно было сделать еще страницы 3-4 назад :)

Я думал до него дойдет.

>> не выделена в функцию функция uncheckedLogin

которая все что делает - это кладет юзера в сессию?

допустим, тебе надо реализовать секурную фичу сообщать юзеру «прошлый раз вы залогинились в ...»

подозреваю, там появиться вторая строчка request.session(«datetime») = datetime

дислексия детектед

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

> Напиши мой код с комментариями.

обязательно, только не сегодня