 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / October 2006Why interface cannot define static methods?
Hi. As title, why? moop™ wrote: > Hi. > As title, why? Interfaces can not be instantiated such as classes, simply because they are in fact not classes. Therefore there is no point in making a static method in an interface, since they are already static by definition. Correct me if anything I said was wrong! - Deniz Dogan > moop™ wrote: >> Hi. [quoted text clipped - 5 lines] > > Correct me if anything I said was wrong! It's wrong. Static methods must have bodies. The methods in interfaces don't have bodies, and are thus not static methods. They're actually public abstract methods. - Oliver moop skrev: > Hi. > As title, why? Because the designers of Java decided that interfaces can't have static methods. Is it possible to design a language with static interface methods (such that concrete classes implementing that interface must declare those methods as static)? Yip. .ed -- www.EdmundKirwan.com - Home of The Fractal Class Composition. Download Fractality, free Java code analyzer: www.EdmundKirwan.com/servlet/fractal/frac-page130.html > moop™ skrev: > [quoted text clipped - 7 lines] > that concrete classes implementing that interface must declare those > methods as static)? Yip. At least in the early days of Java, there was a strong keep-it-simple principle operating. I suspect that static interface methods would have added more complication than they saved. Now, that principle seems to have disappeared. I'm far from convinced that generics, as actually implemented with type erasure, added enough to the language to justify their cost in increased complication. Patricia > At least in the early days of Java, there was a strong keep-it-simple > principle operating. I suspect that static interface methods would have [quoted text clipped - 3 lines] > that generics, as actually implemented with type erasure, added enough > to the language to justify their cost in increased complication. How did that shift happen? It seems originally Java was Gosling's creation, but now there is Java Community Process. Is that how the shift happened? My first take is I prefer Gosling's opinion to a broader sampling. The positive of the shift is that each of the changes was requested and will be used. More Java code will be written faster by those already writing Java code. The negative of the shift is that it makes it more difficult to communicate with other developers. Makes it more difficult to use other people's code. I don't know whether it makes it easier to market Java (to new developers and businesses) because on one hand Java has more features now, but reliability and consistancy is diminished in pitch. Perhaps more Java will be written for the next thirty to fifty years then would be otherwise, but then about eighty years down the line Java will be retired. If the changes had not happened perhaps it would be more likely that Java would be used as a layer for some other technolgoies way in the future. This is quick speculation. Cheers. Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ >> At least in the early days of Java, there was a strong keep-it-simple >> principle operating. I suspect that static interface methods would have [quoted text clipped - 27 lines] > more likely that Java would be used as a layer for some other > technolgoies way in the future. The only programming language I know with fifty years of history is Fortran, and FORTRAN1 was still being designed in 1956. I'm absolutely certain that Fortran would have died long ago if it had not undergone immense increases in complexity over a series of changes. With a sample size of one, it is very difficult to make any predictions about what will happen to programming languages in fifty years time. Patricia > The only programming language I know with fifty years of history is > Fortran, and FORTRAN1 was still being designed in 1956. Don't forget LISP, which was also designed at about that time. /gordon  Signature[ don't email me support questions or followups ] g o r d o n + n e w s @ b a l d e r 1 3 . s e >> The only programming language I know with fifty years of history is >> Fortran, and FORTRAN1 was still being designed in 1956. >Don't forget LISP, which was also designed at about that time. LISP started out as a FORTRAN-library for List processing, so that it seems to be slightly younger than FORTRAN. opalpa@gmail.com wrote: > How did that shift happen? It seems originally Java was Gosling's > creation, but now there is Java Community Process. Is that how the > shift happened? I wonder how many people reading this NG have /not/ been irritated by short-sighted (or just plain stupid) requests for new features from their users ? I wonder how many have /not/ been forced into providing features that they /knew/ didn't add up properly, hadn't been thought out properly, and would likely cause problems in the future ? We are Java's users, and while I think Sun have made many mistakes, I cannot help feeling that the biggest was ever listening to what Java programmers were asking for. -- chris > opalpa@gmail.com wrote: > [quoted text clipped - 12 lines] > cannot help feeling that the biggest was ever listening to what Java > programmers were asking for. How many of us are in a position to ignore our users, particularly in the face of a large and dangerous competitor (for Java, .NET)? > How many of us are in a position to ignore our users, particularly in the > face of a large and dangerous competitor (for Java, .NET)? How is it large and dangerous? .Net has a lot of hype, but apart from ASP.Net, not even Microsoft themselves are using it much. To add static methods to interfaces does not make any sense. IMHO it was even a mistake to allow static final fields there. > To add static methods to interfaces does not make any sense. IMHO it > was even a mistake to allow static final fields there. I have always assumed that the reason for this was that the contract specified by an interface sometimes requires associated constants as part of its definition. As in: interface Moveable { public static final int LEFT = 0x1, RIGHT = 0x2, UP = 0x4, DOWN = 0x8; void move(int direction); } I would say that is sufficient justification for allowing constants. Unfortunately, it also allows abuse... -- chris >> How many of us are in a position to ignore our users, particularly in the >> face of a large and dangerous competitor (for Java, .NET)? > > How is it large and dangerous? .Net has a lot of hype, but apart from > ASP.Net, not even Microsoft themselves are using it much. .NET is growing fast. Java is still bigger. But it is far from given that it will continue to be so. Arne [me:] > > We are Java's users, and while I think Sun have made many mistakes, I > > cannot help feeling that the biggest was ever listening to what Java > > programmers were asking for. > > How many of us are in a position to ignore our users, particularly in the > face of a large and dangerous competitor (for Java, .NET)? Few. But where possible good developers will attempt to manage their users' expectations; will attempt to provide something which gives the customers the functions they need, but not necessarily in the broken form that was asked for. Obviously, that's not always possible, either for technical and political reasons. Where I blame Sun (and they -- even in my book -- only warrant a part of the blame) is in not doing that. I suppose also I think they made a mistake in setting up a "community process" where change is driven only be people who want a given change and think they are capable of providing it, while alowing little or not enough weight to dissenting opinions. -- chris > moop skrev: > [quoted text clipped - 3 lines] > Because the designers of Java decided that interfaces can't have static > methods. You can easily achieve the effect of defining a static method in an interface. Watch and learn: ======================================== public interface MyStupidInterface { public static final Runnable stupidity = new java . lang . Runnable ( ) { public void run ( ) { System . out . println ( "Hello World!" ) ; } } ; } ======================================== public class MyStupidApp implements MyStupidInterface { public static void main ( String [ ] args ) { stupidity . run ( ) ; } } ======================================== > Is it possible to design a language with static interface methods (such > that concrete classes implementing that interface must declare those > methods as static)? Yip. I think you are correct. I tried a variation of that. Is it permissible to implement an interface using static methods? For example using a static void run ( ) method to implement Runnable. It is not permissible with my compiler. Why not, I don't know. > .ed > [quoted text clipped - 3 lines] > Download Fractality, free Java code analyzer: > www.EdmundKirwan.com/servlet/fractal/frac-page130.html Interfaces define a contract of an implementing class. They are, as another poster menioned, implicitly public abstract methods. And you cannot have static abstract methods because static methods are neither inherited nor invoked dynamically. Allowing them in interfaces would just add confusion: Just put them in some class, e.g. a helper class to that interface. > As title, why? Interfaces can't contain implementations. What you can do is define an inner class containing methods. Regards, Lothar SignatureLothar Kimmeringer E-Mail: spamfang@kimmeringer.de PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81) Always remember: The answer is forty-two, there can only be wrong questions! Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.