|
Replies:
14
-
Last Post:
Mar 10, 2006 1:04 PM
by: chandra
|
|
|
|
|
|
|
@Implements annotation
Posted:
Nov 29, 2005 8:53 AM
|
|
|
Random though of the day:
Since we have an @Override annotation, why not an @Implements annotation to indicate that a method helps implement an interface. This would be useful mainly for readability, and also catches any typoes when constructing abstract classes.
package java.lang;
import java.lang.annotation.Target;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
@Target(RetentionPolicy.METHOD)
@Retention(RetentionPolicy.SOURCE)
public @interface Implements
{
/**
* The set of interface that the speficied method implements
*/
Class[] value();
}
e.g.
import java.util.*;
public class SequenceList extends AbstractList<Integer>
{
int start;
int size;
public SequenceList(int start,int end)
{
this.start = start;
this.end = start-end;
}
@Implements(List.class)
public Integer get(int index)
{
if(index < 0 || index >= size)
throw new IndexOutOfBoundsException();
return start+index;
}
@Implements(Iterable.class,Collection.class)
public Iterator<Integer> iterator()
{
return new Iterator<Integer>()
{
int count = 0;
@Implements(Iterator.class)
public boolean hasNext()
{
return count < size;
}
public Integer next()
{
if(!hasNext())
throw new NoSuchElementException();
return start+count++;
}
public void remove()
{
throw new UnsupportedOperationException();
}
};
}
@Implements(Collection.class)
public int size()
{
return size;
}
}
|
|
|
|
|
|
|
Re: @Implements annotation
Posted:
Nov 29, 2005 11:39 AM
in response to: subanark
|
|
|
True - it will pair up with the usage of @Override quite well.
In fact, about standard Annotations - wouldn't @Deprecated be more useful if it has an optional String field which if specified contains the full qualified name to the alternative method?
|
|
|
|
|
|
|
|
Re: @Implements annotation
Posted:
Nov 29, 2005 3:02 PM
in response to: alexlamsl
|
|
|
I thought about this... and I did submit a proposial to one of the annotation JSRs about having other javadoc tags transform into annotations (e.g. Authors). It was ultimatly rejected though since it was thought that the javadocs style was a well accepted practice. @Depracated was added as an annotation only since it does make an actual change in the class file.
|
|
|
|
|
|
|
|
Re: @Implements annotation
Posted:
Nov 29, 2005 3:53 PM
in response to: subanark
|
|
|
oh I can understand your point; I propose this for usages beyond javadocs, though - e.g. friendlier compiler warnings, or even "automatic" legacy code transformation!
|
|
|
|
|
|
|
|
Re: @Implements annotation
Posted:
Dec 1, 2005 12:10 AM
in response to: alexlamsl
|
|
|
Why the heck would we need annotations at all? What's the added value, or is it (as it appears to me) change for the sake of change?
Annotations should never have made it into the language in the first place, let's not force them on people and make them even worse.
|
|
|
|
|
|
|
|
Re: @Implements annotation
Posted:
Dec 1, 2005 8:04 AM
in response to: jwenting
|
|
|
Force? Just like @Override you are not forced to use it, its only a compiler error if you use it incorrectly. And in the case of @Implements, it would only be a compiler error if they method you denote as implementing an interface does not in fact implement that interface.
Annotations are for the most part just standardized comments that can optionality be compiled into the class file (like Depracated). They also help provide richer modifiers without adding another keyword to the language.
Besides its one less thing that a c# programmer cannot complain about java not having feature x.
|
|
|
|
|
|
|
|
Re: @Implements annotation
Posted:
Dec 1, 2005 8:54 AM
in response to: subanark
|
|
|
Don't worry - there are always people who don't have enough resources to accomodate new ideas / innovations, and thus criticise them all and FORCE others from being able to utilise them.
|
|
|
|
|
|
|
|
Re: @Implements annotation
Posted:
Dec 2, 2005 12:45 AM
in response to: subanark
|
|
|
> Force? Just like @Override you are not forced to use > it, its only a compiler error if you use it > incorrectly. And in the case of @Implements, it would > only be a compiler error if they method you denote as > implementing an interface does not in fact implement > that interface. > You are forced to use it because you're always going to have to use the code of others who use it.
> Annotations are for the most part just standardized > comments that can optionality be compiled into the > class file (like Depracated). They also help provide > richer modifiers without adding another keyword to > the language. > They are a keyword in themselves... Designed to turn documentation into code, something that should not be done.
> Besides its one less thing that a c# programmer > cannot complain about java not having feature x.
Which should never be a reason to do anything. It should sooner be a reason to NOT do something.
|
|
|
|
|
|
|
|
Re: @Implements annotation
Posted:
Dec 2, 2005 8:47 AM
in response to: jwenting
|
|
|
Time to feed the Troll...
> You are forced to use it because you're always going to have to use the code of others who use it.
If someone else codes it you can safely ignore it, unless you do an incomplete refactoring and end up changing a method name of an interface that this class implements... and in that case its not to hard to correct, or you could just delete the annotation. The only real concern is weather an annotation actually does modify the behaviour of execution, which for the most part those that are currently implemented in the SDK do not.
>They are a keyword in themselves... Designed to turn documentation into code, something that should not be done.
When I talk about the adding a keyword I mean the problem of a language having too many keywords (or too many uses of those keywords), that requires users of the lanauge to activly know about (like c#). Annotations are kind of like keywords, except they are documented in the same way classes are, and must be imported or fully qualified to use. Image how much better java beans could be annotations were used instead of get___ or set___ method identifing names. Determining functionality at runtime by using patterns method names, class names, or package names, should be avoided!
> Which should never be a reason to do anything. It should sooner be a reason to NOT do something.
That was a joke.
|
|
|
|
|
|
|
|
Re: @Implements annotation
Posted:
Mar 7, 2006 12:48 PM
in response to: jwenting
|
|
|
Why is that you particularly don't like Annotations? I know that using to much Annotations will make another language inside java. And we have to keep the coherence of one language with the force of many. There are situations where Annotations can make things very easy, maybe we should use other form, more integrated with the rest of the language. What is your proposal for removing annotations?
|
|
|
|
|
|
|
|
Re: @Implements annotation
Posted:
Mar 7, 2006 12:49 PM
in response to: kfgodel
|
|
|
Sorry, last post was directed to jwenting
|
|
|
|
|
|
|
|
Re: @Implements annotation
Posted:
Mar 7, 2006 1:07 PM
in response to: kfgodel
|
|
|
Im trying to understand the benefit of @Implements??
@Override is good, I use it and it has helped me out at times.
@Implements, where will it help me out?
The compiler already blows up if Im missing something and tells me: method so and so is not implemented. We also have the implements keyword, which seems clear as well.
leouser
|
|
|
|
|
|
|
|
Re: @Implements annotation
Posted:
Mar 7, 2006 10:06 PM
in response to: leouser
|
|
|
@Implements would pick up for example if I'm writing an abstract class that needs to still implement some methods of its interfaces.
It would also help if methods were removed from an interface, any class that implements the removed method would get picked up by the compiler.
|
|
|
|
|