prave jsem se vystrikal. to bylo semena.
Gratuluji. Mohlo to byt celkem vtione vlakno o neznalostech nekterych lidi a Jave, takhle to tu predpokladam za chvili zamknou...
Hokej v tom máš ty. Já jsem tady mluvil o Streamech abstraktních, řekl jsem, že Java 8 Stream api tuto abstraktnost cti ale InputStream a Jirsák ji nectí. To je jedna věc.
Druhá věc je, že nechci proudově zpracovávat formát, který proudem není, jen tvrdím, že je možné ho proudově zpracovat, ikdyž to znamená, že se musí nejprve celý načíst. To, že se musí celý načíst, neznamená, že to nemůže být proud.
Dokonce jsem jak pro debily uvedl příklad, že běžně existují streamy, které musí bufferovat, aby vytvořily správnou transformaci na výstupu. Ale je to marné, je to marné, je to marné.
Pletes si pojmy s dojmy.
1. Zadna formalni, obecna, presna definice toho, co je abstraktni stream neexistuje, pojem se pouziva obecne
2. Produove zpracovani IO a nacteni celeho obsahu do pameti je logicky nesmysl. Pokud by tomu tak bylo, tak muzeme i DOM API povazovat za streamove
3. Porad nedokazes pochopit rozdil mezi InputStream pro proudovou abstrakci IO a praci s kolekcemi (kde ma vyraz stream uplne jiny vyznam). Nemaji spoli spolecneho vubec nic, krom toho slovicka stream.
4. Pojmy stranou, InputStream je v Jave exaktne zdokumentovany a jasny, jeho vlastnosti vylucuji nacteni zip jinak, nez to dela ZIS. Nacteni do pameti je nesmysl a prave proto je tam ZIS a ZF. ZIS vyuziji presne tam, kde porrebuji to zpracovar proudove, tzn. efektivne
5. IS je od zacatku definovany jako stream bytu pro binarni IO, nacitani jinych datovych typu resi jeho nastavby. Je to IO trida, k nicemu jinemu neslouzi. Specializace typu u ni nema smysl, musel by se definovat serializer a deserializer. A to se realizuje prave jinymi tridami.
6. Kdybys znal poradne aspon ten .net, tak vis, ze tam Stream je taky nad byte. Akorat k tomu ma balast, ze micha zapisy,seeky, cteni nad jedne tride. Java to oddeluje typove, coz se mi libi vic, ale jinak je to fuk.