[Standard] Using public/static/abstract modifiers in interfaces

[Alex Blewitt <Al...@ioshq.com>]

On Thursday, Aug 14, 2003, at 12:01 Europe/London, Jason Dillon wrote:

> Also, as I noted in the coding standards, public and public static are 
> redundant in the context of interfaces and should not be used.

I disagree. They should absolutely be there in interfaces, along with 
the abstract keyword for methods.

public interface GoodExample {
   public static final int CONSTANT = 0;
   public abstract void method();
}

pubic interface BadExample {
   int CONSTANT = 0;
   void method();
}

The reason for this is that if a developer cut-n-pastes a line from the 
interface into a class, the only one that will keep the same behaviour 
is the GoodExample. Missing out keywords leads to potential problems.

It also makes it trivial to change it from an interface to a class, or 
to create a subclass by copying the interface and changing the top line.

There was a discussion in Eclipse re: generating methods w/o some of 
the modifiers that got bounced to the top of the Eclipse PMC about 
this. Their conclusion was that it didn't hurt to have the modifiers 
in, and it actually avoided those problems outlined above.

Since an IDE will put these in automatically in most cases, I can't see 
any reason for wanting them taken out.

I would say that the standard should read:

You SHOULD put in public abstract for methods, and pubic static final 
for constants, but it is not mandatory to do so.

Alex.

(It is also generally considered bad practice these days to define 
constants in an interface and implement it just to gain access to those 
components; this should probably be put in the standards as well IMHO)

Re: [Standard] Using public/static/abstract modifiers in interfaces

[Alex Blewitt <Al...@ioshq.com>]

On Thursday, Aug 14, 2003, at 12:14 Europe/London, Jason Dillon wrote:

> I disagree, but could you at least put the license on from 
> spec/LICENSE.txt

Unfortunately, I'm not a committer -- I was just bringing up the point 
re: interfaces. If someone else hasn't picked up on it yet (not looking 
at that bit of code myself) it might be a good idea to submit a patch; 
that's probably a good way of getting it done ....

Alex.

Re: [Standard] Using public/static/abstract modifiers in interfaces

[Jason Dillon <ja...@coredevelopers.net>]

I disagree, but could you at least put the license on from 
spec/LICENSE.txt

Thanks,

--jason


On Thursday, August 14, 2003, at 06:10  PM, Alex Blewitt wrote:

> On Thursday, Aug 14, 2003, at 12:01 Europe/London, Jason Dillon wrote:
>
>> Also, as I noted in the coding standards, public and public static 
>> are redundant in the context of interfaces and should not be used.
>
> I disagree. They should absolutely be there in interfaces, along with 
> the abstract keyword for methods.
>
> public interface GoodExample {
>   public static final int CONSTANT = 0;
>   public abstract void method();
> }
>
> pubic interface BadExample {
>   int CONSTANT = 0;
>   void method();
> }
>
> The reason for this is that if a developer cut-n-pastes a line from 
> the interface into a class, the only one that will keep the same 
> behaviour is the GoodExample. Missing out keywords leads to potential 
> problems.
>
> It also makes it trivial to change it from an interface to a class, or 
> to create a subclass by copying the interface and changing the top 
> line.
>
> There was a discussion in Eclipse re: generating methods w/o some of 
> the modifiers that got bounced to the top of the Eclipse PMC about 
> this. Their conclusion was that it didn't hurt to have the modifiers 
> in, and it actually avoided those problems outlined above.
>
> Since an IDE will put these in automatically in most cases, I can't 
> see any reason for wanting them taken out.
>
> I would say that the standard should read:
>
> You SHOULD put in public abstract for methods, and pubic static final 
> for constants, but it is not mandatory to do so.
>
> Alex.
>
> (It is also generally considered bad practice these days to define 
> constants in an interface and implement it just to gain access to 
> those components; this should probably be put in the standards as well 
> IMHO)
>

Re: [Standard] Using public/static/abstract modifiers in interfaces

[James Strachan <ja...@yahoo.co.uk>]

I agree. Most Java code uses public even though its redundant in 
interfaces. We're really splitting hairs if we worrying about this 
kinda thing. Lets focus on J2EE! :)


On Thursday, August 14, 2003, at 12:10  pm, Alex Blewitt wrote:

> On Thursday, Aug 14, 2003, at 12:01 Europe/London, Jason Dillon wrote:
>
>> Also, as I noted in the coding standards, public and public static 
>> are redundant in the context of interfaces and should not be used.
>
> I disagree. They should absolutely be there in interfaces, along with 
> the abstract keyword for methods.
>
> public interface GoodExample {
>   public static final int CONSTANT = 0;
>   public abstract void method();
> }
>
> pubic interface BadExample {
>   int CONSTANT = 0;
>   void method();
> }
>
> The reason for this is that if a developer cut-n-pastes a line from 
> the interface into a class, the only one that will keep the same 
> behaviour is the GoodExample. Missing out keywords leads to potential 
> problems.
>
> It also makes it trivial to change it from an interface to a class, or 
> to create a subclass by copying the interface and changing the top 
> line.
>
> There was a discussion in Eclipse re: generating methods w/o some of 
> the modifiers that got bounced to the top of the Eclipse PMC about 
> this. Their conclusion was that it didn't hurt to have the modifiers 
> in, and it actually avoided those problems outlined above.
>
> Since an IDE will put these in automatically in most cases, I can't 
> see any reason for wanting them taken out.
>
> I would say that the standard should read:
>
> You SHOULD put in public abstract for methods, and pubic static final 
> for constants, but it is not mandatory to do so.
>
> Alex.
>
> (It is also generally considered bad practice these days to define 
> constants in an interface and implement it just to gain access to 
> those components; this should probably be put in the standards as well 
> IMHO)
>
>

James
-------
http://radio.weblogs.com/0112098/