I'm against merging AEOutputStream and AEFileOutputStream. Separation is not only about usage, but about logical separation into abstract entities too. From that point of view, it makes perfect sense to separate the generic output stream from it's current file implementation.
I don't have strong feelings about merging AEDataFile into AEFileOutputStream, especially as it's an interface that doesn't define any interface at all, just a few constants. I don't think anything external depends on this, but I'll let Tobi have the final comment on this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As part of https://sourceforge.net/p/jaer/tickets/110/, maybe the AEDataFile could become real interface (abstract void write()), and the re-implementations would redefine the constants & write() (writeInt()/writeByte()) as these are coupled to the output-format?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm against merging AEOutputStream and AEFileOutputStream. Separation is not only about usage, but about logical separation into abstract entities too. From that point of view, it makes perfect sense to separate the generic output stream from it's current file implementation.
I don't have strong feelings about merging AEDataFile into AEFileOutputStream, especially as it's an interface that doesn't define any interface at all, just a few constants. I don't think anything external depends on this, but I'll let Tobi have the final comment on this.
I agree on OutputStream and FileOutputStream;
As part of https://sourceforge.net/p/jaer/tickets/110/, maybe the AEDataFile could become real interface (abstract void write()), and the re-implementations would redefine the constants & write() (writeInt()/writeByte()) as these are coupled to the output-format?