Paul Clapham

kd murphy,
Your post was moved to a new topic.
(This informational message will self destruct in two days)

I've noticed that when I look through my old code, I notice code sections which go through the entries in a List and, for those satisfying a certain condition, do such and such, and so on. I find that if I convert those to use stream processing, the result looks cleaner and moreover, it's more self-explanatory.

Case in point: There's some code which, whenever an entity is changed, all the other entries related to it need to be modified appropriately. For a long time I had been thinking that those modifications didn't need to be done sequentially, but could be done in separate threads. And when I tracked down the code and changed it to use streams, it turned out that all I had to do was to use ".parallelStream()" instead of ".stream()". No need to write code to build and start threads, just let Java do all of that.

Although I wasn't working with languages similar to Java in 1995, it's my impression that Java was the first language to commit to Unicode. This was actually a radical step, since such languages tended to have the "poverty viewpoint". Minimization of space and time was very important and the idea of using two bytes when only one was (almost always) necessary would have been a great extravagance. They could have chosen to store text data in an array of bytes with "code points" being a way of storing characters which needed more than 8 bits (UTF-8), but instead they decided to keep it simple and define String the way they did. I'm sure there was a lot of griping about that, with people storing their text data in byte arrays to save space.

Ironically they were forced to implement "code points" later, when UTF-16 wasn't enough!

Rob Spoor wrote:No, you need to change it to <Soap:Envelope xmlns:Soap="http://www.w3.org/2003/05/soap-envelope"><Soap:Header>
The prefix and namespace need to match. Whether that's env or Soap shouldn't matter, but some clients are unfortunately not smart enough to check for the namespace but check the prefix instead.

That was (and is) the answer to the question. But perhaps it isn't the answer to your question? Post some details about what you have in your XML and what you want to see instead and people can discuss.

Steve Dyke wrote:A remote data look up get a date 04/25/2025.

Okay. But is this date value in that code a LocalDate, or an SQLDate, or some homebrew sort of date, or what?

I think that your technique of trying to imagine how the Java runtime is actually implementing "x++" is getting in your way. What it does is to increment x and then return the original value of x as the result of the expression. There's no need to imagine the machinations under the covers as it does that, you only need to remember that "x++" returns the original value of x. That's all. When you start imagining hidden variables and assignments you just add extra conceptual load to your understanding which is unnecessary.

For another example consider the expression "(3 + 6) * (2 + 3)". To compute this, the runtime computes 3 + 6, then it computes 2 + 3, then it multiplies the results of those two calculations. No doubt it has to store those two calculated values somewhere before it multiplies them. But there's no need to imagine hidden variables and assignments to describe where they are stored -- because it's totally unnecessary to care how that works. I'm sure you never gave that example a second thought, though. Likewise there's no need to obsess over how "x++" works.

(As I understand it, those temporary results are stored in a stack in real life, and I expect "x++" results in something being stored in that stack too, but you don't need to care.)

Well, yeah, if you try to parse a string like '2022-04-25' using the format 'MM/dd/uuuu' it isn't going to work. The most straightforward fix would be to use a format which matches the format of the strings you're producing.

Although I find it a bit odd that the second line is working with something which understands dates, then turns it into a string only to immediately convert the string to something which understands dates. Wouldn't converting from the date-understanding thing directly to LocalDate be more reliable?

Anil Philip wrote:I want to create an array of String using
new String("Buonaserata") as the constructor, not an array containing nulls.

How about this ?"Buonaserata".toCharArray()Admittedly it doesn't use the constructor you asked about, but then there isn't any such code which could fulfil that requirement. And also it produces an array of chars, not an array of Strings, but perhaps one could build on it. A Stream with a Collector maybe.

I don't wish to be not nice, but this thread is, let's say, not useful. It's true that the expressions ++x and x++ have different values, given some variable x. And many students have had difficulty with that. But really that's all you need to know. Those two expressions have different values, and the rule for what differs is fairly simple. So when you use those values in subsequent code, you have to understand the difference.

However there is no point in expanding upon the idea of "use". You might use those values by assigning them to a variable, or by using them as a method parameter, or by doing arithmetic with them, or in some other way I haven't thought of. But it makes no difference at all, the values of those expressions are the same no matter what. So going on about assignments, for example, is not useful.

I find it's easier to look for simple explanations for bits of computer languages. Writers of computer languages generally use simple concepts, unlike writers of fiction. So going on about nonexistent complications is not useful.

Anil Philip wrote:I did not say expressions, I said operators.

Let's review where you said "operators" and what you said, then. You'll have to copy and paste what you said, though, because you've said a lot of things including those two words.

Anil Philip wrote:I meant that

++i;
and
i++;

result in the same value.

That's an unambiguous statement, then. Which is a false statement.

It's true that the value of the variable i is the same after either of those operations, but you made a statement about the values of those expressions. Not the same.

Anil Philip wrote:For the same kind of operator, there is no difference between pre and post operations - outside of an assignment.

You seem to be asserting that "6 + (++a)" is not different than "6 + (a++)". There's no assignment here.

That is much nicer than the original code, but it assumes that all of the peculiar complexity of the original code is unnecessary. Which may in fact be true, but I didn't want to assume that.

Yes, that sounds right. Give it a try and see what goes wrong.