нет.. это ты меня не понял.. в ява есть анотация @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