Nyeng Gyang

Ranch Hand
+ Follow
since Jan 11, 2021
Cows and Likes
Cows
Total received
1
In last 30 days
1
Total given
0
Likes
Total received
1
Received in last 30 days
1
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Nyeng Gyang

Paul Clapham wrote:Yes... you do seem to have trouble understanding explanations, don't you?


I have had no prblems understanding the following explanations:

Jesse Silverman wrote:I don't think I see additional benefits from using BufferedFileWriter over FileWriter if all writes are always done in sizes >= the buffer size anyway.

Stephan van Hulst wrote:Multiple contributors have pointed out that in such a case, there is no benefit.


The only explanation that I am having a hard time understanding is an explanation that is presented as though it is different than the information furnished in the above two quotes.

Paul Clapham wrote:Not only that, you do seem to require explanations for almost everything. It seems hardly worthwhile trying to provide explanations since you aren't going to understand them anyway.


I will continue to request for as much explanation as I require and readers of such requests I make will continue to be at liberty to either entertain these requests and provide me the requested information or disregard/ignore the requests and decline to provide me the information.

Stephan van Hulst wrote:I added that such a case is purely academic. In practice, you would virtually never pass an array of such a large size to the read() method, because there is no good use case for it.


This additional information you provided is moot to my inquiry. It is enough for me to know that the advantage, which you describe exists only in a purely academic case and not in practice, is not an advantage (under the right condition) of using the buffered classes over the non-buffered classes. So long as you, or any other contributor to this discussion thread, continues to present this "advantage" as an advantage of using the buffered classes over the non-buffered classes, I will continue to remark that I don't see this alleged advantage of using the buffered classes over the non-buffered classes.

Stephan van Hulst wrote:The original code is just a demonstration of how using a buffered stream can increase throughput when compared to a bare file stream.


Stephan van Hulst wrote:Yes, you can change the amount of bytes read from the stream to coincide with the size of the buffer used internally by the buffered stream, and it will effectively make the buffered stream pointless, but such a scenario is not probable in the real world.


In the foregoing quotes of remarks you made, you are simply having a debate with yourself and, unfortunately, this debate does not assist me in any way.

Stephan van Hulst wrote:In the real world, you typically only want to work with a handful of bytes at a time, not thousands. Requesting only a handful of bytes at a time from a file without buffering input is extremely slow.


Unfortunately, this remark you have made does not provide adequate information to educate me, regarding my inquiry in this discussion thread.

Stephan van Hulst wrote:I will not waste my time.


You are, of course, entitled to respond in this way. Your time is provided by you only as you allow it, not as anyone either cajoles, coerces or forces you to.

Stephan van Hulst wrote:Your "rules" are overly complex, unnecessarily loquacious, and plainly put, a headache to read.


Again, you are entitled to this opinion, which I don't happen to share with you. The rule I have come up with will guide me to not write code that will generate that compiler error again. You are liberty to read those of my posts or comments that are adequately clear to you and to ignore those that are not.

Stephan van Hulst wrote:Once again you insist that any confusion in this matter is caused by all except the imperspicuity of your own posts.


This remark by you is either sincerely (inadvertently) erroneous or provably deliberately disingenuous, but I can't say that I know which of these two possibilities is the case.

Paul Clapham wrote:And yeah, one of the great things about Java is that you don't need to spend your time reinventing wheels.


I can't say that I disagree with you that reinventing wheels is a wasteful effort. However, I am yet to see how setting the array size on line 7 of the code I provided, to the ostensible default buffer size when the buffered classes are used, is any more than truly zero effort. With this effort having a magnitude of zero, this fact is hardly tantamount to an effort exerted in reinventing an already invented wheel.

Paul Clapham wrote:Not only is BufferedReader better than what you or I would write because it already exists and it requires zero time to choose it, it has been around for a long time and all of the tricky edge cases that you or I might miss when we reinvented it, those are all taken care of.


I would be happy to learn of all the ways in which, as you put it, "BufferedReader [is] better than what you or I would write." In all our deliberations and discussion in this discussion thread, I am yet to be provided information that explains and illustrates this claim. Don't get me wrong, I am not disputing that this claim is accurate; rather, I am simply saying that the claim is yet to be adequately explained to me.

Jesse Silverman wrote:As both the book and earlier replies in this thread have stated, there is generally a huge difference between buffered and non-buffered IO performance, quite dramatic.


The "huge difference between buffered and non-buffered IO performance," of which you speak in the foregoing quote, seems to me to be considered moot (i.e., under the right condition), by even you yourself, in the following quoted remark you made:

Jesse Silverman wrote:I don't think I see additional benefits from using BufferedFileWriter over FileWriter if all writes are always done in sizes >= the buffer size anyway.


Jesse Silverman wrote:The idea that once one figures out an optimum buffer size, the work is done, and thus the Buffered* classes are unnecessary, because then one will only read or write that size of data at a time, is indeed deciding to take on the responsibility of buffering oneself, as I described earlier in the thread.


Like I already mentioned earlier, there is zero extra effort taken, in the example code I provided, to implement the code using the non-buffered classes, instead of using the buffered classes; in other words, setting the array size on line 7 of this code, to the ostensible default buffer size when the buffered classes are used, is indeed zero effort.

Jesse Silverman wrote:Is there an objective experiment that could be performed to tell the difference??


In the foregoing quote, you speak of a "difference." However, this information you provide (which speaks of some "difference") seems to be already subsumed in the following information you provided earlier in this discussion thread:

Jesse Silverman wrote:I don't think I see additional benefits from using BufferedFileWriter over FileWriter if all writes are always done in sizes >= the buffer size anyway.


Kindly refer to the code example I provided in the first post I made, which started this discussion thread. If the array size on line 7 is changed from, for example, 100 to 8192 then the long description you provided alludes that the following will happen (please, correct me if I have gotten you wrong anywhere):

(1.) The read operations that happen on lines 13 and 22 will attempt to read 8192 characters at a time (i.e., this much data will be attempted to be read, whether the non-buffered or buffered classes are used).

(2.) The write operations that happen on lines 15 and 24 will attempt to write as many characters, at a time, as the integer value stored/held in the char_length identifier (i.e., this much data will be written, whether the non-buffered or buffered classes are used).

The discussion in the study guide advises that an effort needs to be exerted, in order to determine an optimal buffer size. However, this effort to determine an optimal buffer size would need to be exerted whether some code implementation uses the non-buffered classes or it uses the buffered classes. Does your long description seek to demonstrate that this is not the case? If your long description seeks to demonstrate this then I still can't see how it has done so.

In summary, and in other words, your new information, about some "difference" between the behavior of the buffered and non-buffered classes, seems to already be captured by the old remark you made; however, of course, correct me if I am wrong about this).

Stephan van Hulst wrote:Paul's point is that it's not helpful to generate additional rules that are overly complex, especially when they're not even correct.


While everyone would agree that rules ought to be simple, rather than complex, I hope you do realize that Paul persisted at addressing the rule that I had already replaced with a new one. Any further discussion and/or critique of this old rule, by anyone reading this discussion thread, will indeed only muddy the waters and, thereby, not help the discussion. Any and all critiques should be of the new rule, not the old one.

Stephan van Hulst wrote:There really is no need to make it so difficult:

1) The compiler determines what overload will be called, based on the formal type of the reference you're calling the method on AND the formal types of the method arguments.

2) Of the overload picked by the compiler, the runtime determines what override it will call, based on the actual type of the reference you're calling the method on.


If you would take a moment to compare your quoted remarks above with my updated rule, you will definitely see that your remarks pertain to the determination of which of multiple overloaded methods would be invoked at runtime, while the rule pertains to the compile-time determination of which of an overloaded/overridden method and an overloading/overriding method that would be invoked, in the particular case/example of polymorphism in the code I provided. That you have provided your remarks, which I have excerpted in the foregoing quote of yours, demonstrates that you also are yet to avoid the conflation of which I have been speaking; the same one that Paul and Jesse are also yet to be able to avoid.

Stephan van Hulst wrote:On the other hand, Reader has no readLine() method declared, so the compiler can't determine an overload to be called, so it raises a compiler error.


And, what does this compiler error say? It says that the compiler can't find a readLine() method implemented/provisioned in the Reader class, not the BufferedReader class. The compiler tries to find a readLine() method implemented/provisioned in the Reader class, rather than one implemented/provisioned the BufferedReader class, despite the fact that the actual type of the identifier used is BufferedReader, not Reader; clearly, the compiler does this because the formal type of the identifier is Reader. This is the heart/core of what my updated rule covers.

Stephan van Hulst wrote:That the actual type would be BufferedReader is of no consequence, because the application never reaches runtime.


Yes, of course, it is true "that the actual type would be BufferedReader is of no consequence," as you opine, but only if one doesn't care that the compiler reports this error and fails to compile the code. However, since I would like to write code that does not even generate this particular error in the first place, I find my updated rule to be of consequence in this regard.

Stephan van Hulst wrote:If you need to rewrite it to a set of rules that only make sense to you, that is fine, but we can't help you with those, because they don't make sense to us.


I have already noted that my initial conflation of two issues, which ought to have been separated from the onset, is responsible for my inquiry here to not make sense to you folks. This is precisely the reason why, now that I have identified this conflation, it is not useful to perpetuate it, since doing so will only perpetuate my inquiry not making any sense to you. They say that hindsight vision is 20-20; this is true in this case for which I now realize that I should have not only separated the two issues I conflated, but that I should have, in fact, also placed them in entirely different discussion thread questions.

P.S.:

Since the terms "formal" and "actual" types already exist, I guess this means that my suggested "syntactic" and "semantic" types, respectively, are redundant because, unless there is/are some scenario(s) that I am overlooking, I suspect that my suggested terms mean exactly the same thing as their counterparts, which already exist.

Jesse Silverman wrote:That sounded/sounds like you believed that your example shown most recently, i.e. ... Would yield the output ...


I actually thought that I was the only one conflating the issues that I have already explained I was conflating and then hoped that we would all advance past this conflation. However, seeing that both you and Paul have continued to be unable to avoid this same conflation, I am led to believe that all of us were actually deeply involved in the conflation, so much such that even you persist in advancing the conflation in your response from which the foregoing quote has been excerpted.

In particular, my updated rule has to do with the method that the compiler would construe should, rather the method that would, be invoked (by the JVM) at runtime. Consequently, no, I did not (and do not now) believe that my code example would yield an output that ends up to not be the output actually yielded. Indeed, like I already explained in my response to Paul earlier, I provided this code, "just to underscore that the issue has been settled," to use the same words I used in that post I made. The other issue is the one captured in the updated rule I provided. My code, to which you referred, has to do with the method that would be invoked at runtime, which is an issue that has already been resolved as well as one of the two issues that need not be conflated.

Jesse Silverman wrote:EDIT -- I think I see where the problem lies in the interpretation of your re-formulated Rule 2: ...


The part of your response, which follows the foregoing quote of your remarks, perpetuates the conflation of the following subjects/issues (1) The one addressed by my updated rule 2 and (2) The one about the method, including which of multiple overloaded methods, that would be invoked at runtime. Once again, to be clear, that updated rule has to do only with the method that the compiler would construe should be invoked at runtime. If I am repeating myself, this is because you are yet to see and/or acknowledge the conflation, of which I have been talking about.

Jesse Silverman wrote:There are at least two ways you could be confused about this question.


While I truly appreciate and am grateful for your having taken both the time and effort provide responses to my inquiry here. You seem to not have apprised yourself with the resolution that has already been achieved on the issue I raised. Like I have already mentioned in a previous post I made above, kindly check certain posts in this discussion, which have already brought the matter to a resolution. You seem either to not have seen these posts or to have seen them, but not fully apprised yourself with their content.

Paul Clapham wrote:I'm still of the opinion that generating excessively complicated rules is unhelpful, but on the other hand people have to work through things for themselves to arrive at a proper understanding.


Practically every aspect of computer programming is the existence and application of rules, whether it is the programmer following these rules as they write code or it is the compiler checking whether a programmer has followed these rules as well as enforcing that a programmer follows the rules.

Jesse Silverman wrote:What Nyeng is saying above can happen in C++ if ...


Jesse Silverman wrote:This is one of those times I think he just needs to go back and review that material.


We have gone past this issue. It has been resolved. Please, refer to the previous few posts here to apprise yourself of how the issue has already been resolved.

Jesse Silverman wrote:If I recall correctly it would be impossible to get thru the end-of-chapter tests in the appropriate areas successfully while remaining confused about this issue.


There is no confusion, since the issue has been resolved.

Paul Clapham wrote:That still seems wrong to me. Let me try to apply the original example to that.


Paul Clapham wrote:So under this interpretation, the rule is not correct.


Why continue the discussion with the old rule 2, which I have replaced with a new one? Recall that I have noticed that our discussion is better conducted if two scenarios, which arise due to the polymorphism in the code I provided, are separated from each other? These two scenarios are as follows:

(1.) The compiler's determination of the appropriate method that should be invoked during runtime. Even though the JVM, and not the compiler, runs the compiled bytecode, the compiler nonetheless fails to successfully compile the code with the polymorphism in this code.

(2.) The method that gets invoked at runtime. This issue has been settled and, just to underscore that the issue has been settled, I wrote the following code to test exactly which method would be invoked and the result of running this code shows that the overriding method (in the subclass) is the method that gets invoked:
Thanks for pointing out that the JVM, and not the compiler, runs the bytecode generated by the compiler, unlike how my choice of words, albeit only in a couple of instances, says. However, take a look at the second rule I provided earlier in this discussion thread, which I provide verbatim as follows:

(2.) When an instance method of a class gets overridden, a (reference) identifier, which is declared to be of the class type and that is used to access/reference the method, will invoke only the overridden method in the class (not the overriding method in the subclass); this rule applies whether the reference assigned to the identifier is for an object of the class or an object of the subclass.

Neither this rule nor some of the other discussions I provided rely on a claim or understanding that the compiler runs bytrecode. This wrong wording I employed does not amount to a misconception, as you construe and allege in the following remark you made; rather than this wrong wording being a misconception, it was due to brief moments of absent-mindedness; trust me, even though I am learning things about Java that I did not know before, from studying this study guide, I know enough of Java to know that the compiler generates bytecode and the JVM executes this generated bytecode:

Paul Clapham wrote:... this is a misconception. The compiler does not try to invoke anything. It's the JVM which invokes methods. I suspect that misconception might be the reason you find yourself confused here.



Paul Clapham wrote:We were discussing the second half of that description, namely which version of the method (subclass or superclass) is invoked at runtime.



Paul Clapham wrote:Now you ask about what happens at compile time, which is a separate issue.


The last two of the foregoing quotes, from your response, make me to revise my second rule as follows:

When an instance method of a class gets overridden and a (reference) identifier, which is declared to be of the class type, is used to access/reference the method, the compiler will construe that the overridden method in the class (not the overriding method in the subclass) is the method to be invoked at runtime; this rule applies whether the reference assigned to the identifier is for an object of the class or an object of the subclass.

And, yes, just like you said in your other post/response, I built that second rule "based on the idea that the person reading the code can know the type of the variable and also the type of the object it refers to." This rule, as well as my proposed concepts of "syntactic" and "semantic" types, are definitely only for cases in which both the declared type of a reference identifier and the type of the object whose reference is assigned to the identifier are known, to either the compiler or a human reader of the code, at compile time.

I accept responsibility for the misunderstanding caused by my conflation of the following two scenarios, which arise due to the polymorphism in the code I provided: (1) Compile-time determination of the appropriate method that should be invoked during runtime and (2) The method that gets invoked at runtime. With the benefit of hindsight, I should have employed wording and a discussion that precludes this conflation on my part. Thanks for your contributions and answers to my inquiry.

Jesse Silverman wrote:It is possible that this section might possibly have been written slightly clearer, but when they say ...


For me, it isn't so much that the quoted sentence is truly unclear as it is that the context, in which the sentence is provided, suggests that the performance improvements discussed in that section of the book are those very same ones that we have agreed are not performance improvements offered by the buffered classes (i.e., the buffered classes do not provide the performance improvements, over the non-buffered classes, of enabling a programmer to copy larger data chunks).