|
Replies:
6
-
Last Post:
Mar 29, 2008 2:09 PM
by: i30817
|
|
|
|
|
|
|
Now that people actually can use the kitchen sink.
Posted:
Mar 20, 2008 7:42 PM
|
|
|
I have one problem with java.
Its not geared towards future proofing. Its said it is, but its mostly about the past, (compatibility, compatibility, compatibility).
This is a general thing, but there are some areas where things could be alleviated, philosophical points aside.
One of these is interfaces.
Interfaces were born because of the so-called diamond problem, where people who designed code in C++ would inherit from many classes making for a really messed up inheritance hierarchy. So java just removed the implementations from the classes. Thus classes would have cohesion, since everyone would have to implement things anyway.
I agree to this. It is a nice solution. Unfortunately there is just one thing. Interfaces make damn hard to program to interfaces and at the same time, have future proofing.
THERE IS NO WAY TO ADD A METHOD TO A INTERFACE.
So there are endless discussion of "when are you going to add sort to abstract lists wah-wah".
This is what is wrong with interfaces: by not adding this capability they forced everyone to use Abstract classes as the base of libraries, making true genericity impossible (ironic).
Many people, myself included think that adding state to interfaces is akin to invoking the devil. Well you can have functions without state. Just make interfaces like stateless abstract classes, make a warning that overriding a interface function with a body can gain you efficiency and is recommend and implement a (as efficient as possible without state) version of the function.
Voila, future proofing of interfaces, and libraries with interfaces instead of goddamn abstract classes.
|
|
|
|
|
|
|
Re: Now that people actually can use the kitchen sink.
Posted:
Mar 21, 2008 3:49 AM
in response to: i30817
|
|
|
Methods have been added to interfaces in java.sql on several occasions. Old code implementing those interfaces continues to work provided you don't call one of the new methods.
Perhaps the JVM could be enhanced so that when a (non abstract) class was loaded that did not implement a method of an interface, it could generate a method that delegated to a static method in some class. It would just need a dictionary of available delegations. This would only be used where necessary to solve the backward compatibility issue that you raise.
|
|
|
|
|
|
|
|
|
Re: Now that people actually can use the kitchen sink.
Posted:
Mar 21, 2008 1:19 PM
in response to: mthornton
|
|
|
Question: if old code implementing interfaces is fine so long as you don't invoke any of the new methods, why is this really a problem?
How could you expect to invoke a JDBC 2.0 method against a JDBC 1.0 interface? You seem to suggest the interface should provide some default implementation which JDBC 1.0 implementations would inherit as defaults and a JDBC 2.0 implement in a more efficient manner.
Off the top of my head, this sounds like an extremely rare use-case to me. How often can you really retrofit defaults that make sense across all implementations? It seems to me it is both easier and safer to simply update your JDBC 1.0 implementation by implementing the new methods.
I suspect from the first post that the author didn't know you can add interface methods without breaking old code so long as new methods are not invoked.
|
|
|
|
|
|
|
|
|
Re: Now that people actually can use the kitchen sink.
Posted:
Mar 22, 2008 8:31 PM
in response to: cowwoc
|
|
|
So why is no one adding (for ex) sort to List?
I guess because people are not suddenly going to implement sort in their lists, and then (in a new part of the codebase) the sort method is called, since it is so obviously convenient.
The alternatives are using the @since anotation to hide these in IDE's but this is a cop-out, since a language is not a IDE's and metadata will not(SHOULD NOT) save you from runtime errors.
The problem exists.
|
|
|
|
|
|
|
|
|
Re: Now that people actually can use the kitchen sink.
Posted:
Mar 22, 2008 8:37 PM
in response to: i30817
|
|
|
Another example : CharSequence has charAt(int) (an obviously random access construct) but no char [] getChars(char [] chars, int i, int len) (also an obviously random access construct that can be built on charAt, but for efficiency would be built on the private structure of the class).
I want both, the possibility for a lazy developer that implemented CharSequence before to use a safe convenient call (even if inefficient if not overloaded) and the opportunity for library or jdk developers to use interfaces as the facade of libraries (for testing, mocking, flexebility, etc).
In fact CharSequence is a vexing example, since its the only shared point between many normal and final classes.
The only alternative is to use the most common class (String) as facade (flexibility--, efficiency--), or go into instanceof inferno (i seem to recall nio buffers suffering here for some reason).
|
|
|
|
|
|
|
|
|
Re: Now that people actually can use the kitchen sink.
Posted:
Mar 29, 2008 7:37 AM
in response to: i30817
|
|
|
Ok I am not sure what you're saying. Are you saying that you want the want a new method on List or that you can't make a new method on List yourself or that you can't extend the interface List to SortableList?
I know you know you can extend interfaces and add methods so what is it you want that Java doesn't give you ?
RE: the rationale behind interfaces.. it's not just the triangle problem, it's implementation inheritance generally that's problematic. See Joshua Bloch's Effective Java for details. I never extend anything and have no problems programming all kinds computer science-y (as opposed to J2EE) applications and libraries intended and used for public consumption.
So I am not understanding exactly what it is you feel is missing, which is not to say yo don't have a point, but just to say I am not getting it!
|
|
|
|
|
|
|
|
|
Re: Now that people actually can use the kitchen sink.
Posted:
Mar 29, 2008 2:09 PM
in response to: swv
|
|
|
Not myself. I know i can extend the list interface easily and use that in my applications.
I'm talking mainly about adding (stateless) methods to the JDK or popular libraries here, but not on abstract classes, but on interfaces.
Everyone thinks its best practice to program to interfaces (for various reasons) yet, in practice almost no (popular) library does, since that would constrain the public interface too much. They normally create a interface, but use a abstract class (constraining the public api). The List sort() is only a example.
I want some safety for library developers to add a (stateless) method to a old interface (a version 1.1) so that the clients.
1) Don't need to implement the method themselves, in their implementations. (they should be encouraged to - so add a warning about this)
2) Library developers use interfaces in libraries.
I also had some thoughts about more extreme ways to do this. (A kind of read-only interface, where the library developer was the only one that could implement it - a library level final). Then the library developer could change the public api, since it would be the only implementor. But there would still be need of manual tweaking for removing or modifying methods.
|
|
|
|
|
java.net RSS
