Re: abstract static methods (again)
On 19 Pa=BC, 19:53, Tomas Mikula <tomas.mik...@gmail.com> wrote:
On Oct 19, 3:51 pm, Marcin Rze 1/4 nicki <marcin.rzezni...@gmail.com>
wrote:
On 19 Pa 1/4, 15:06, Tomas Mikula <tomas.mik...@gmail.com> wrote:
I'm saying it is wrong, but just don't like that the implementation
requires a lot of reflection. (I don't mind that implementation of
statndard Java API requires reflection, because someone has already
implemented it for me. But if I want to create my own serialization
framework (e.g. for xml serialization), I need to do a lot of
reflection which could be automated.) Probably one thing I find wrong
with readObject - as I already mentioned, it prevents the object to b=
e
immutable. Though this could also be solved by declaring it static an=
d
use reflection.
Yes, but someone did it for you either - JAXB, xStreams etc. This is
not a type of work you do day-in day-out, so benefits are rarely to be
seen
Occasionally new frameworks appear. Not an everyday work, but for me
it justifies the introduction of a new feature, if there is no hidden
danger we haven't noticed so far. I accept that for you it's not a
sufficient reason.
It is, but I am trying to bring up some dangers of your method
throughout this thread.
Example with generics can easily be substituted by some kind of
"trait" parameter
Sorry, I don't know what you mean by "trait" parameter? Do you me=
an that
I would call the zero() method on some instance?
Like myDummyVector.zero()?
I borrowed the terminology from C++. More or less, you add type
parameter (let's say <Zero extends ZeroVector>) which has a method
like getZeroVector() (strictly speaking ZeroVector has this method)=
..
Actual type parameter provides concrete implementation.
I don't see how this would help. Would I call Zero.getZeroVector()?
Probably you meant something else because this leads to the same
problem with calling static method getZeroVector() on a type
parameter. Could you provide an example?
OK
public class MyVector<T, Zero extends ZeroVector> extends Vector2D<T>
{
...
public MyVector(Zero zero) { this.zero = zero; }
...
}
MyVector<Integer, Zero2D> vec = new MyVector(Vector2D.zero());
OK, but when we already resort to obtaining a zero vector from another
instance, we don't need a reference to zero stored in each instance of
vector. We can just have a nonstatic zero() method:
abstract class Vector<T, V extends Vector<V>> {
public abstract V zero();
}
class Vector2D extends Vector<Integer, Vector2D> {
public static final Vector2D ZERO = new Vector2D(0, 0);
public Vector2D zero(){ return ZERO; }
}
I wanted to obtain zero without a reference to an instance. Using an
instance is unnatural and sometimes an instance is just not at hand.
Right, but that was just an example of what is 'trait'. I am not
saying this is necessarily the best design decision in this case.
Right but implementation of addition surely checks for this case,
doesn't it?
Not necessarily:
abstract class Vector<V extends Vector<V>> {
public V add(V v);
}
class Vector2D extends Vector<Vector2D> {
private final int x, y;
public Vector2D(int x, int y){ this.x = x; this.y = y; }
public Vector2D add(Vector2D v){
return new Vector2D(this.x + v.x, this.y + v.y);
}
}
No checking that the argument of addition has the correct type,
because this is enforced by the compiler.
Formal arguments have to be invariant with respect to overriding in
Java, you simply created method overload which will be used when
compiler is sure that runtime type of argument will be Vector2D. You
will still have to provide 'generic' add method.
Your example does not help either (or I cannot see how it would)
because you will not be able to dispatch on v's actual type unless you
change how invokestatic works.
Yes, consider
public abstract class IOStream //for reading disk streams {
public abstract static boolean isReadable(File f) //returns true
for files which a concrete class can hopefully process.
...
}
public class LocalIOStream extends IOstream {
public static boolean isreadable(File f) { return f.isLocalFile(); }
...
}
public class AudioVideoStream extends LocalIOStream {
???
}
in AVStream you have, if I understood you correctly, two choices -
either to redo all work of super-classes which is not really an
option, let's say,
public static boolean isReadable(File f) { return f.isLocalFile() &&
(f instanceof AudioFile && ((AudioFile)f).getAudioCodecID().equals
(...);}
You don't have to redo the work, you can call the superclass's static
method as usual:
public static boolean isReadable(File f){
return LocalIOStream.isReadable(f) &&
f instanceof AudioFile &&
((AudioFile)f).getAudioCodecID().equals(...);
}
Yeah, right, but consider what happens when someone implements
multiple interfaces, or when inheritance tree changes, or when someone
inherits multiple interfaces with conflicting statics and so on. This
example is basically hand-crafted implementation of virtual
dispatch :-)
Furthermore, if we expect that specialized IOStreams will only be able
to process instances specialized instances of File, the IOStreams
could be parametrized by the type of the File.
abstract class IOStream<F extends File> {
public abstract static boolean isReadable(F f);
}
class LocalIOStream<F extends File> extends IOStream<F> {
public static boolean isReadable(F f){
return f.isLocalFile();
}
}
class AudioVideoStream extends LocalIOStream<AudioFile> {
public static boolean isReadable(AudioFile f){
return LocalIOStream.isReadable(f)
&& f.getAudioCodecID().equals(...);
}
}
Well, ok, but it does not change anything. Still you have to re-
implement invokevirtual by hand all the time :-)
or omit it so then you impose different context. Namely, pretend to be
able to read remote files while you are not.
And one more question:
//client code
Stream s = new AudioVideStream(..);
read10Bytes(s);
public byte[] read10Bytes(Stream s) {
if (!Stream.isReadable(file)) //how would you dispatch it? There is no
way I suppose
}
This would be a compile-time error, since isReadable() is abstract in
Stream.
This is really bad :-) Then actually your statics will be usable only
when you know exact type you want to work with.