After looking closely at the OutStream API, I have some remarks about virtual methods/fields in OutStream:
Currently, print and printLine are virtual, but are just convenience methods for writeChars. So instead of declaring those two methods as virtual, I think the virtual methods here should actually be writeChar and writeChars. Futhermore, if someone wants to implement in Fantom an OutStream that supports only non-binary writes (like StrBufOutStream for example), writeChars and writeChar would have to be overriden.
Why endian and charset are virtual? I don't see a case where I would need to override these. The reason I ask this question is that if we allow overriding of these fields, OutStream.java would probably require some fixes to take it into account. In the current implementation, some methods access the value of endian or charset through the internal field rather than through the getter. Personnaly, I think the API would be clearer if these fields were not virtual.
What are your thoughts about that?
MoOmSun 8 May 2011
And I guess the same should apply to InStream. i.e.
declaring readChar and readChars as virtual
moving endian and charset to non-virtual fields (or making sure that these fields are always accessed through their getters)
brianMon 9 May 2011
I am not sure why endian and charset are virtual. I think that might be hold over from before we had some of the field features. I don't have any problem making those non-virtual. If this will break anyone's code, please speak up now.
I originally make print and printLine for covariance, but that has since been solved with the This type. So I say we can make those non-virtual too.
The reason that the char methods are non-virtual is that the charset determines how to encode/decode character codes into bytes. The only role of a subclass should be to how to perform I/O of those bytes.
So unless there any objections, I will be make all of those non-virtual for next build.
MoOmMon 9 May 2011
What you propose seems fine with me.
The only problem I see if readChar and readChars are not virtual, is that it'll be impossible to implement a character-only OutStream (like StrBufOutStream). Currently, the java implementation of StrBufOutStream overrides those two methods to append characters to the StrBuf, and it overrides write and writeBuf to make them throw exceptions (as a StrBuf does not support binary writes).
But if someone would like to implement the same thing directly in Fantom, it'll be impossible. Not sure it's a real problem though.
MoOm Sun 8 May 2011
After looking closely at the OutStream API, I have some remarks about virtual methods/fields in OutStream:
print
andprintLine
are virtual, but are just convenience methods forwriteChars
. So instead of declaring those two methods as virtual, I think the virtual methods here should actually bewriteChar
andwriteChars
. Futhermore, if someone wants to implement in Fantom anOutStream
that supports only non-binary writes (like StrBufOutStream for example),writeChars
andwriteChar
would have to be overriden.endian
andcharset
are virtual? I don't see a case where I would need to override these. The reason I ask this question is that if we allow overriding of these fields, OutStream.java would probably require some fixes to take it into account. In the current implementation, some methods access the value ofendian
orcharset
through the internal field rather than through the getter. Personnaly, I think the API would be clearer if these fields were not virtual.What are your thoughts about that?
MoOm Sun 8 May 2011
And I guess the same should apply to
InStream
. i.e.readChar
andreadChars
as virtualendian
andcharset
to non-virtual fields (or making sure that these fields are always accessed through their getters)brian Mon 9 May 2011
I am not sure why
endian
andcharset
are virtual. I think that might be hold over from before we had some of the field features. I don't have any problem making those non-virtual. If this will break anyone's code, please speak up now.I originally make
print
andprintLine
for covariance, but that has since been solved with theThis
type. So I say we can make those non-virtual too.The reason that the char methods are non-virtual is that the charset determines how to encode/decode character codes into bytes. The only role of a subclass should be to how to perform I/O of those bytes.
So unless there any objections, I will be make all of those non-virtual for next build.
MoOm Mon 9 May 2011
What you propose seems fine with me.
The only problem I see if
readChar
andreadChars
are not virtual, is that it'll be impossible to implement a character-only OutStream (like StrBufOutStream). Currently, the java implementation of StrBufOutStream overrides those two methods to append characters to the StrBuf, and it overrideswrite
andwriteBuf
to make them throw exceptions (as a StrBuf does not support binary writes).But if someone would like to implement the same thing directly in Fantom, it'll be impossible. Not sure it's a real problem though.
brian Fri 27 May 2011
Promoted to ticket #1526 and assigned to brian
brian Fri 27 May 2011
Ticket resolved in 1.0.59
I removed the
virtual
from these slots: