Sujet : Re: New VSI post on Youtube
De : clubley (at) *nospam* remove_me.eisner.decus.org-Earth.UFP (Simon Clubley)
Groupes : comp.os.vmsDate : 21. Aug 2024, 13:18:46
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <va4lv6$3rpl4$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13
User-Agent : slrn/0.9.8.1 (VMS/Multinet)
On 2024-08-20, Arne Vajhøj <
arne@vajhoej.dk> wrote:
On 8/20/2024 1:38 PM, Simon Clubley wrote:
You forgot about InputStreamReader() to turn an InputStream into a Reader. :-)
>
There are InputStreamReader to convert from InputStream to Reader and
OutputStreamWriter to convert from OutputStream to Writer.
>
And they are actually used, because some API's has classes that only has
getInputStream()/getOutputStream() methods and not
getReader()/getWriter() methods.
>
All follow the model.
>
After all, why miss the opportunity to have two parallel sets of APIs
(byte versus character) instead of just the one API ? :-)
Goodness knows why they didn't just add something like String's getBytes()
method to the character APIs or add character support to the byte APIs...
>
Because InputStream/OutputStream and Reader/Writer are fundamentally
different.
>
I may not have stated that clearly enough.
The character model is built in top of a byte model, with character-specific
knowledge in the character classes.
The traditional Java way to add this additional functionality is to extend
a class in a subclass and implement the additional functionality in the
subclass.
I am having a hard time seeing why they didn't just extend the byte I/O
classes in this way to implement additional character functionality so
that both character and byte I/O directly uses an InputStream (and likewise
for an OutputStream). There should be no need for a character-specific
Reader concept or an InputStreamReader() converter.
Simon.
-- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFPWalking destinations on a map are further away than they appear.