пишу JSF, и пришёл на мысль, что ...


сравните два блока





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

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

компилятор мог бы сделать if блок из данной серии анотаций  

Добавлено через 6 минут и 1 секунду


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

polosatij,  а  не проще спросить у разработчиков  (мыло, форум, личка)???
При чем тут форумчане Винграда ?  Вроде никто с  САНовцами не знаком.   

Операции производятся над ними, сами аннотации ничего не делают.


это мне напоминает макросы в С++.

Проще? Что описано во втором примере - вообще непонятно.

polosatij, вы хотите предложить свой язык программирования?

нет, их навалом уже.. хотелось бы сделать всё как можно проще..  

Добавлено через 8 минут и 19 секунд


мысль проста.. сделать проще оператор if   

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

Для простого советского программиста 1-ый блок адназначна проще.

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

в if-е постоянно разные значения.. и нет смысла выделять всё в ещё один метод..




значит, я не простой и не советский программист.. у меня уже рябит в глазах от постоянных if else




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

И напрасно вы его не видите. Лопата что бы копать, а топор что бы рубить. Не наоборот.

Аннотации внутри методов - есть.

А если точнее, то внутри метода аннотации могут быть объявлены только для локальных переменных. Автору топика "помогли бы" аннотации для участков кода. Но увы.

LSD,      
    Молодец, пришел и все, что тут написанно выше перечеркнул    

LSD, 

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



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



всего-то навсего десяток случаев и всё..



немного не понял, что ты хотел сказать.. увы, такого нет?

Повторю предыдущего оратора: прекрати забивать дрелью гвозди, и закручивать шурупы молотком  

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

судя по вашей логике, мне не надо было писать анотации, а нужно было оставить "страшные" и тупо повторяющиеся конкструкции с if-ами или самому писать reflection.. таким образом я описал около 500 тестов за пару недель..

а чем не устраивает такой вариант? вся логика вынесена в setUp и tearDown, анотации помогают мыставить мета данные на запуск и на окончание данной методы.. так что же мешает или что плохого сделать такое на часть кода внутри методы вместо тупо "повторяющихся" if-ов?    

Позвольте полюбопытствовать - где в вашем примере закодирован if?

if successful
else unsuccessful

@TestResult ожидает именно такого результата в стеке от этой методы..   

Не вижу что-то. Конструкция if закодирована в tearDown(). Аннотация TestResult - не более, чем статичная метаинформация и ничего нигде не ожидает   

анотация TestResult, как и другая анотация ничего и ожидать не будет.. всё зависит от value стоящей в ней.. это такая же метаинформация, как и в моём первом примере в этом топике..   

А мета информацию кто обрабатывает?  Не Демон-Гослинга же 

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

Тут налицо явное непонимание 


А как выполняются эти тесты? Через reflection загружается список методов с их аннотациями, потом в зависимости от метаданных из аннотаций эти методы специальным образом вызываются. Аннотации то всё равно относятся не к коду метода, а к методу целиком. 

Как правильно сказал LSD, если ты поставишь аннотацию в произвольном месте, то кто её в этом случае должен обрабатывать? Аннотации -- они не исполняются сами по себе, они только интерпретируются каким-то отдельным обработчиком.

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

вот это вот жалко.. не было времени эксперементировать..   



ех.. 

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

Это не паттерн Command случаем?

Ну, в некотором роде -- да, только у меня ключевое слово "любого метода" 
И, кстати, спасибо -- ты упоминанием паттерна подкинул мне идею, как обяъснить всю нелепость вопроса этой темы.
Вот исходный пример:

Если автор уж очень хочет делать аннотации к вызовам методов, то в нынешнем синтаксисе Java это выглядело бы как-то так:

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

PS: Я не уверен, что в аннотациях можно использовать такие конструкции (вычисляемые во время выполнения). Мне не приходилось с ними плотно работать и есть подозрение, что там можно использовать только константы. Так что может эту задачу вообще нереально решить аннотациями 

Это сообщение отредактировал(а) Дрон - 1.10.2008, 15:53

Дрон, вот ты намутил  

мой вопрос был не написать wrapper, это бы я и сам смог.. мой вопрос был, почему "нет" анотаций вместо непрекращающихся if-ов   

А кто анотации бы обработал?

Я вообще не понимаю о чем спор. Нету такого и хорошо что нет и врятли когда-нибудь будет. А все остальное - это "Вот как бы нос Иван Иваныча да к лицу Иван Никифорыча" (с) Гоголь

Ты меня совсем не понял. Мой ответ был не о том, как написать обёртку, а о том, что для реализации того, что ты хочешь, каждый вызов любого метода должен быть завёрнут в подобную обёртку (пусть даже и неявно).


Угу. На этом объяснения заканчиваю, ибо до цели они не доходят   

Это сообщение отредактировал(а) Дрон - 2.10.2008, 10:48

нет.. это ты меня не понял.. в ява есть анотация @SuppresWarnings, что говорит о том: не надо бросать warning  в этом блоке => мне итак понятно, что тип соответствует действительности..

я говорю о annotation для компилятора, а не про annotation "вызываемых" по время runtime..   

Ну тогда, то о чем ты говоришь просто синтаксический сахар. Писать if лень и ненаглядно, а писать аннотации - не лень и наглядно.

Если уж так охота, то попробуй написать НБНФ нотацию для таких аннотаций, и посмотри не будет ли там противоречий.

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

я не совсем понял, что это значит.. можно по подробнее?   

продолжая тему о анотациях!  


бывают ситуации:

abstract object A
abstract doSomething();

object A1 extends A
object A2 extends A

в такой ситуации A1 и А2 обязаны имплементировать методу doSomething();
иногда есть случаи, когда A2 не должна иметь методу doSomething(); в этих случаях бросают Exception, как было бы не плохо не бросать Exception, что будет throw в Runtime, а написать анотацию, что данный метод не может быть вызван и это будет известно на этапе компиляции   

(3) продолжая тему о синтаксическом сахаре..

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

Нормальная Форма Бэкуса-Наура (иногда её сокращают до БНФ)



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

Добавлено через 3 минуты и 42 секунды

Ну и чем код:

лучше чем:

?

Писанины даже больше. И вот такой код:

порождает вопрос: какой класс должен использоваться для new Date()?

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



это я вообще не понял к чему сказано для этой темы..



1). не "java.util.Date", а просто java.util.Date
2). а такая конструкция тоже хороша?!






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

... и к которому (Exception-ну) никто не готов  
Ты знаешь какой Exception выкидывается когда нужный метод в классе отсутствует? И почему именно такой?



Ты знаешь что такое контракт функции? Или тебя интересует почему выбрасывание недекларированного Exception-а нарушает контракт?



1. можно и так, не суть важно
2. Ну так это ИМХО уже проблемы разработчика, что он не может в одном проекте придумать не пересекающиеся имена для классов


Ты не понял, в моем примере для компилятора есть как минимум 3 возможности:
- создать объект типа java.util.Date
- создать объект типа java.sql.Date (он приводим к java.util.Date)
- создать объект типа Date (наш самопальный класс определённый в дефолтовом пакадже)
И вовсе не очевидно, что он должен выбрать.

всё равно тебе придётся в методу встроить throw "new RuntimeException()";
если проект большой, то занимаешься простой ерундой с copy & paste, причём никто тебе не гарантирует, что ты при больших объёмах, запаришься и просмотришь что-нибудь..



нужнА   



=> RuntimeException() + декларирование анотации в допустимом классе



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

если получается Date extends Date => принимая во внимание, что у нас annotation   а значит добавляем параметер и дело решено   

За такое нужно вешать. За йайца.

ты предлогай варианты   

скажи мне, пожалуйста, как ты собираешься решать возникшую траблу, если Error и Warning пришли с чужим lib??

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

1. Импортнуть. А полностью квалифицировать то, что покороче. 
2. Не использовать дебильные либы.

ЗЫ. А вообще лучше решать реальные задачи, а не высасывать непонятно что из пальца.

Это сообщение отредактировал(а) fixxer - 2.10.2008, 16:38

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



  вот это ты сказанул.. ЩАЗ я по твоей подсказке, выкину из проекта пару либов.. ты не врубаешься о чём речь идёт      



, опять же, наверх и прочитать всё.. 

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

Это сообщение отредактировал(а) fixxer - 2.10.2008, 16:52

это ты из каких соображений собираешься сделать?

1). path для того и другого почти одинаковый и длинный
2). они оба используются очень часто

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

Реальный пример приведи.

Такой случай очень редок. Чтобы и вложенность пакетов одинаково длинная, и чтобы использовались одинаково часто в коде класса, и чтобы оба из сторонних библиотек. Но уж если случилась такая беда можно и пожертвовать ООП в угоду читабельности, а именно обернуть в свой класс, чтобы не было прямых упоминаний в коде имени того страшного класса, а все вызовы через геттер myWrapper.getThatDamnClassObject().theMethod(). Это изврат, да, но что ж поделаешь если такая оказия приключилась?

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

Это сообщение отредактировал(а) fixxer - 2.10.2008, 17:26

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

Чтобы, так сказать, расставить точки над Ё. Мое мнение такое:

Зачастую бывает так, что вместо того чтобы действительно решать проблему, люди придумывают различные workaround'ы, порой фантастические. Типа: "Вот неплохо было бы иметь такую конструкцию, она сразу бы решила мою локальную проблему", - вместо того чтобы искоренить первопричину. Обратимся к началу топика. Проблема, как я понял, в том, что часто приходится писать ветвления со сложным условием, порой с одинаковыми конструкциями в условиях в различном их сочетании. А это, к гадалке не ходи, как правило означает проблемы в проектировании. Например перегруженный функционалом класс или наоборот размазанный по иерархии функционал. Как правило такие проблемы можно решить перепроектированием классов и их взаимодействия. Локализовать ответственности, разбить на более мелкие, но умные классы или применить, к примеру, State/Strategy, ну или сгруппировать и обернуть условия в более явные и предметные предикаты.

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

В любом случае разговоры типа "А не плохо если бы..." беспредметны.

Или изобрести наконец алиасы, почему их до сих пор нет в Java мне не понятно

Добавлено через 12 минут и 5 секунд


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

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




угу.. ты попап в самую точку   





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

на примере



теперь по сабжу.
Если не ошибаюсь, Стандарт JSR-308 , который будет входить в 7ю яву , описывает как использовать аннотации вместе с типами (переменными).
например можно будет объявлять 
@NotNull
Integer a;
Но кроме этого будет возможность создавать свои аннотации с изощерённой логикой ... проверками, условиями и т.д...



Это сообщение отредактировал(а) v2v - 2.10.2008, 23:15

Че-то я  очкую (с)

http://www.michaelnygard.com/blog/2008/05/..._jsr_308_t.html
http://dmlloyd.blogspot.com/2008/05/closer...at-jsr-308.html
http://bc-squared.blogspot.com/2008/05/wha...va-wrought.html

если в работе намечается рутина, может просто пора ... поменять работу?  

От блин, но автор вот тут правильно заметил, что это уже чересчур. Вообще как я где-то читал и полностью согласен -- на самом деле исходный код чаще читается людбми, чем пишется. Я бы не хотел в такой галиматье разбираться. Это напоминает мне жуткие и абсолютно нечитаемые конструкции с шаблонами к которым в итоге пришёл С++.

Это сообщение отредактировал(а) Дрон - 3.10.2008, 09:33

Ну и что здесь такого, что занимается логикой работы программы ? Ну да - есть ОПИСАНИЕ того, как надо инициализировать переменную. И что ? Это заменяет if ? 

Я подозреваю, что меня тут сразу забанять за наезд, но по-моему Вы занимаетесь самолюбованием - ах, посмотрите, какую штуку я тут придумал. Про таких Мичурин говорил, что "они готовы скрестить что угодно с чем угодно и получить совершенно непонятный результат" (не гарантирую за точность высказывания - давно встречал).

Надо строить то, что реально может быть востребовано и может помочь в работе. А то, что предложено в начале топика - полный идиотизм.

Вот! Прямо в точку.

Кстати, у меня идея появилась по поводу всех этих @NotNull. На самом деле тут уже совсем другая штука получается, вовсе не "умные самоисполняющиеся аннотации", да и всё необходимое уже есть. Например, можно было бы реализовать нормальную поддержку константных объектов:



Нужно всего-то сделать процессор для apt, после чего заполучить полные штаны счастья  Точно так же уже сейчас можно сделать и пресловутый @NotNull.

Это сообщение отредактировал(а) w1nd - 3.10.2008, 11:28

Проще Scala канонизировать

Тьфу... Есть же любители всё опошлить  

Это сообщение отредактировал(а) w1nd - 3.10.2008, 11:41

Да пользы было бы больше. Ты почитай ссылки на блоги, что я давал.
Я не хочу такого мусора из аннотаций в Java. За ними кода не видно.

Насчёт пользы я сильно-сильно не уверен. Ни scala, ни ruby, ни любые другие надстройки, думаю, никогда не приживутся. 


Во-первых, этот "мусор" уже есть, метаться поздно. Во-вторых, чем вам не угодило вдруг использование аннотаций по прямому их назначению?

Это сообщение отредактировал(а) w1nd - 3.10.2008, 11:53

2all agains annotations, 
не знаю не знаю ... в JPA ведь уже давно реализованы такие аннотации и они пользуются большой популярностью из-за своего удобства.


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


Это сообщение отредактировал(а) v2v - 3.10.2008, 13:19

За свою практику в C# я регулярно пользуюсь всего одной аннотацией (в .net они называются атрибутами), которая к тому же не влияет на выполнение или компиляцию кода: DebuggerStepThrough - говорит отладчику, что не надо заходить внутрь метода.
Помимо прочего эпизодически приходилось пользоваться атрибутами для контроля сериализации: вроде NonSerializable - аналог ключевого слова transient в Java, и ещё какими-то на эту тему, сейчас уже не вспомню.

v2v, ты прав, никто не заставляет так писать -- но ведь, как я уже сказал: код приходится читать чаще, чем писать. А читать подобную ересь тяжело.

В .net проблема "неприсвоения" null в некором роде решена просто, там есть структуры (value type), которые не могут принимать null (хотя основное назначение value type совсем другое). Простейший пример структуры - примитивные типы вроде int, double и т.п.
С другой стороны описанная проблема вызова ToString(), когда переменная равна null тоже в некотором роде решена оператором ?? в C#, то есть я могу написать (something ?? "zzz").ToString() и тогда в случае если something == null будет использована строка "zzz"
Но это всё частные случаи -- просто вспомнилось 

Добавлено @ 13:31
Возможно, меня смущает плохая читаемость аннотаций в Java из-за их синтаксиса. В .net принято писать [BlaBlaBla] вместо @BlaBlaBla и это мне нравится, потому как @BlaBlaBla у меня блоьше ассоциируется с переменными в SQL.

Это сообщение отредактировал(а) Дрон - 3.10.2008, 13:36

Когда аннотации к месту они хороши. В JPA, EJB3, для декларативной демаркации транзакций, для IoC в spring и guice, для fine-grained security, при назначении аспектов, для сериализации JAXB, для вебсервисов. То есть в тех местах, где из задача ортогональна функционалу основного кода. А вот когда аннотации начинают влиять на исполнение самого кода или даже компиляцию - это имхо перебор.

Это сообщение отредактировал(а) fixxer - 3.10.2008, 13:37

В точку!

И, кстати, да -- хороший пример аннотации: декларативные транзакции, или декларативное security, мне правда не приходилось им на практике пользоваться, но "в домашних условиях" тестировал 

Вообще-то аннотации в первую очередь для "влияния на компиляцию" и создавались :whlistle А как раз аннотации, обеспечивающие транзакции/безопасность/etc - это и есть аннотации, влияющие на исполнение. Что-то господа ортодоксы ломанулись в другую крайность  

Это сообщение отредактировал(а) w1nd - 3.10.2008, 13:45

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

хоть что-то новое узнали   



человек говорящий это явно болеет самомнением.. 

---

тынц 

Все Exception должны быть за декларированы, в том числе и RuntimeException. И если разработчик базового класса, решил что этот метод можно не реализовывать, то ему надо просто за декларировать что метод може выбрасывать UnsupportedOperationException и проблема решена (в Collection API полно примеров такого подхода). Разница между:

и

не настолько велика, чтобы ради неё менять язык.

А если тебе приходится в 100 классов реализовывать пустые методы и просто выкидывать в них исключение, то это опять же означает только плохое проектирование. Например в том же Collection API можно было бы сделать, два интерфейса List и унаследованный от него MutableList (при условии конечно, что востребованность ummutable листов было бы велика).




Это проблема конкретного проекта и конкретных разработчиков, что у них хватило фантазии только на то, чтобы ошибку назвать Error. И вводить ради этого в язык новые сущности, не есть хорошо.

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



Наличие или отсутствие анотации @Entity никаким образом не влияет на возможность мною использовать этот бин, ни на исполнение кода этого бина. У меня может не быть никакой JPA, никакого персистанса вообще. Тем не менее я вполне могу использовать этот бин для каких-то своих черных целей.



То же самое. Эти аннотации предоставляют информацию другим частям проекта. Они инфраструктурные.