Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: =?UTF-8?B?Sm9zaHVhIENyYW5tZXIg8J+Qpw==?= Newsgroups: comp.lang.java.programmer Subject: Re: Java blunders Date: Mon, 28 Jul 2014 08:35:39 -0500 Organization: A noiseless patient Spider Lines: 39 Message-ID: References: <38c5efcc-315c-4b8d-a478-89e352af7143@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 28 Jul 2014 13:36:01 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="8cedddb29338592f734c41b16a68fadc"; logging-data="15843"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+RVl1YcBjJJcPLoEqXFrLRCHNXyQtnEUE=" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 In-Reply-To: Cancel-Lock: sha1:0sdE5wICJBA6J8SVIG3Vy/j8yTE= Xref: csiph.com comp.lang.java.programmer:29392 On 7/28/2014 7:33 AM, Chris Uppal wrote: > Joshua Cranmer ?? wrote: > >> You are making some presumptions here that I don't think are entirely >> true. The problem with I/O is, in part, there's no one-size-fits-all >> solution. Recursive descent parsers, for example, often really need >> blocking, "synchronous" [1] I/O to make them readable and maintainable. >> Many servers might care about zero-copy file-to-network streams, which >> requires different infrastructure. A database would rather just treat an >> entire file as a large block of memory (perhaps with detailed hints to >> kernel prefetching and page table management). Sometimes people want >> combinations of these approaches. > > I think that most of the cases you mention would be handled perfectly well by > normal method based syntax. After all there's no reason to use the same style > of design or notation for such completely different kinds of IO. I don't disagree. There's room for disagreement on how to design or notate I/O, but it seems fairly clear that it's nothing that the extremely versatile way of method notation can't handle. The GP's proposal to bake it into the syntax does generally imply a more one-true-way discipline, though, which is what I was objecting to. > The other case I can think of is where you want to "map" a file into memory in > the style of memmap() -- but not necessarily restricting yourself to > OS-supplied features. In such cases it would be most natural to present the > mapped data as if it were a large byte[] array. Again Java lacks the > expressivity to support that. might care to disagree. If I may tie this in with the other ongoing discussion on operator overloading, ByteBuffer sounds like one of those cases where overloading operator[] might make sense. :-) -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth