Так вроде это вещи из разных классов. Future нужен, чтобы не ждать результата, т.е. он обеспечивает возможность вызывать функции асинхронно. А NIO - это неблокирующее IO. В nio-сокетах можно ведь запустить Future на выполнение? Если во future не использовать блокирующие операции, то всё будет асинхронно.
Или я ошибаюсь?
@bimeg Почему не подходят? Future вроде бы как раз и позволяет запускать асинхронно куски кода.
V get(long timeout, TimeUnit unit) позволяет ставить таймер на исполнение кода.
stackoverflow.com/questions/2758612/executorservic...
Вот вроде то. Сам я в яве с асинхронностью не работал, поэтому конкретных классов не скажу. Просто общий смысл такой, что нужно создать Future, и запускать его нужном месте. В питоне, например, это IOLoop: бесконечный цикл, в котором можно исполнять задачи не блокируя IO. И в этом IOLoop есть внутренний таймер, по которому можно ограничивать Future.
В яве асинхронность сделана на потоках, так что тут будут детали различаться, но смысл такой же.
@emeraldsinner И первую функцию стоит переработать, а то на неправильных данных она сломает всё. А если xml вдруг будет другой структуры или поломанный, то и подавно всё полетит.
Вообще, можешь прислать пример этого xml (на pastebin, например, скинь)? Я бы помог в написании нормального парсера.
@anatoly60 Для свойств лучше использовать декоратор @property, а не getattr. Последний вариант очень трудно анализировать статически, чтобы автодополнение было нормальным. Да и с точки зрения написания кода проперти лучше/нагляднее/проще.
Ну а так, можно использовать #: для тех мест, где докстринги непозволительны (например, классовые поля). Также, автодополнение работает и для keyword-аргументов методов, если использовать kwargs.get()/kwargs.pop().
Проблемы с автодополнениями возникают, когда используются метаклассы и другие "рефлекторные" штуки, сильно меняющие поведение объектов.
@Sali_cat
Твои ответы пахнут юношеским максимализмом. Знал я одного человека, он вполне серьёзно намеревался на DarkBasic'е сделать игру, которая бы затмила Warcraft III. Угадай, чем всё это закончилось. Сколько было уже "революционных %любое направление% нового поколения", которые потыкали и забыли. А за деньги даже тыкать не станут.
Конечно, ты убедил себя, что за 14 дней ты узнал весь рынок, но в реальной жизни всё немного по-другому.
Плюс, ты забыл про раскрутку. Со мной работают рекламщики, и я знаю, как трудно раскрутить что-либо. А закрытый и платный продукт раскручивать в несколько раз труднее. У вас есть профессионалы в этом деле? Если нет, то ничего не выйдет.
Снимай розовые очки, устройся на работу и узнай, как всё на самом деле происходит.
@begemot_sun
Какую? Для специфических задач нанимают программиста, чтобы он с нуля писал под конкретную задачу.
14 дней назад автор не знал, какой язык выбрать, а сегодня уже собрался продавать свою супер-цмс. Самому не смешно?
Да, это теория. Потому что на практике никто не станет покупать очередную ПХП-цмску, их и так очень дофига.
CMS без хорошего комьюнити - почти ничто. Те, кто использует другие cms не перейдут на новую. Новички увидев, что продукт платный и им очень мало кто пользуется тоже не станет ковыряться в нём.
У проекта с открытыми исходниками есть хотя бы шанс взлететь.
Яндекс так пишет, например. Вполне обоснованно. Почитай про БЭМ, про действительно важные оптимизации CSS/JS/HTML.
А экономить байты на именах классов (тем более, что любой сервер умеет в gzip) выйдет себе дороже при разработке и поддержке.
Tomcat - это просто контейнер сервлетов. Он включает только поддержку сервлетов, JSP и JSF. А GlassFish и WildFly - это полноценные сервера для веб-приложений (в которых в роли контейнера сервлетов как раз и выступает томкат). В них есть поддержка множества других стандартов. Например, JAX-RS или JPA. Для томката всё это нужно ставить отдельно, выбирая между конкретными реализациями стандартов (например, для JAX-RS можно взять либо Jersey из GlassFish, либо Resteasy из Jboss/WildFly). Т.е. в мавене нужно указывать и пакет со спецификацией API и конкретную реализацию этой спецификации. В случае с веб-серверами, в pom.xml нужно только добавить спецификацию и указать provided. И если надо будет сменить сервер, не придётся изменять реализации спецификаций, так как реализации будет поддерживать сам сервер.
Плюс, в серверах есть очень удобная работа с JPA-ресурсами: БД ты настраиваешь на сервере, а в приложении получаешь доступ через JDNI-строку. Захотел сменить БД - изменил соединение на сервере, не затрагивая исходники ни одного из задеплоенных приложений. Ну и ещё много плюсов. С другой стороны - томкат легковесный, чего порой нельзя сказать о полноценных серверах.
А вообще - это дело привычки/вкуса/предпочтений/требований заказчика или ещё чего-нибудь. Лично я пускаю всё на WildFly, и в мавен-файле стараюсь избегать конкретных реализаций спецификаций, перенося все проблемы на веб-сервер. Ну и как-то были большие проблемы с использованием EntityManager с локальными ресурсами JPA, теперь всё настраиваю на сервере и использую JTA.
Вроде как нельзя так. В принципе, я такого не видел ни в одном фреймворке. Там в маппингах УРЛ используются либо регэкспы (как в джанго), либо что-то очень упрощённое (как во фласке).
@BrakeGames Так не стоит делать, например, потому что при наследовании от нескольких классов у тебя будет всё плохо. А супер умеет нормально учитывать наследование.
Ну. Переведи же нормально. Суть в том, что старые классы (т.е. которые не наследуются от object) фигово работают с супер. Создавай классы в новом стиле.