Re: @Override
On 24.07.2012 23:14, Silvio Bierman wrote:
On 07/24/2012 03:36 PM, Robert Klemme wrote:
On 24.07.2012 00:22, Silvio Bierman wrote:
Using an annotation is, as with
almost all uses of annotations, a poor attempt at making up for the lack
of a proper language feature.
That is nonsense. The mere fact that users can define their own
annotations along with handling these annotations demonstrates that
annotations solve problems which cannot be tackled by changing a
language's syntax. Annotations add *arbitrary* meta data to language
constructs; if all these would have to be handled by a language change
you would need a new Java for every custom library which requires
additional meta data.
In all what you say below you do not address my argument. I take that
as agreement.
Well, I already really dislike annotations for their use in frameworks
like for example Hibernate or for all examples I have seen in "user code".
Do you have other arguments against annotations besides "dislike"?
(Btw., many people actually like JPA over previous versions of EJB
persistence just because lengthy XML files have been replaced by a few
annotations.) Do you at least concede that having the option to add
user defined type safe meta data to language constructs is a totally new
feature which allows to do things which cannot be done without?
But to use it for plain language level constructs like @Override,
@NotNull etc. is plain ugly. Why have keywords like final, public, etc.
at all, then?
It may be ugly - but it may actually be the best solution considering
all effects of language changes. I did not think through all the
effects of such a language change, did you?
This way the language gets polluted using the generic annotation hammer.
Leave it be or actually fix it! I would applaud a bold language revision
that breaks backward compatibility for the benefit of fixing the
language. I could even imagine an annotation that could hint the
compiler at what language version a source is targeting.
I am glad that it's not you who decides about the further evolution of
Java. These dramatic changes all too often look like a good idea
initially - and later turn out to be a nightmare when implemented
without thoughtfully considering all effects of that change.
The term "software" creates the illusion that code can be changed at
will. But in reality changing code (especially when it's part of a
public API) does have a cost - and it can be significant. I suspect
that this illusion is one of the reasons for so many project failures.
Cheers
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/