Women in Technology

Article:		Readable Java 1.5
Subject:		eachof
Date:		2003-09-27 19:46:50
From:		anonymous2
I find the eachof syntax quite readable. It resembles a type declaration as used in mathematics. And it is a natural fit - Decl x : y means that the values of x will range over the values in the collection b. This therefore works kind of like a universal quantifier. On the other hand, the proposed eachof syntax is less clear. When I see a statement like int x = eachof y, then the next question to ask is what happens if I do this int x = eachof y + eachof y? See, the problem is that the "eachof y" really forces a specific kind of execution - it has to work like a queue where values are read off it - something that will require more careful consideration of the particular runtime behavior of the JVM. On the other hand, the Decl x : y syntax is more declarative in nature. There's fewer "gotchas", the scope of the eachof statement and the region of code to be iterated is clearly bounded. (It was suggested that it should simply bind the the nearest loop, in the same way as continue and break, but then we might also have the question of "what if we don't want to attach to the innermost loop?" - surely, to be consistent, the syntax should support eachofs that refer to a label - and, finally, it isn't clear what behavior is desirable when the size of d and e (in your example) are not of equal length - whatever is chosen will simply lead to confusion among users.

Showing messages 1 through 2 of 2.

• Re: eachof
  2003-09-28 09:58:29  sjungels [View]
  
  
  Thanks for responding. I assume you mean that you find Sun's "for :" syntax quite readable, not my "eachof" syntax. You make an interesting point, but I suspect type theory is too esoteric as a basis for the syntax in a language for the masses such as Java.
  
  Programmer's are more likely to have seen the ":" used in basic set theory, for example,
  
  
  
  S = { x : 0 < x <= 1},
  
  <br>
  where ":" is pronounced "such that." This could have been the basis for a nice collections iterator, for example
  
  
  
  for (String x : x elementof C)
  
  
  
  where C is a collection. But the Java 1.5 proposal doesn't do it that way, and the colon character by itself is still cryptic, as I argued in the article.
  
  

  
  The issues you raise in the second paragraph apply only to the extended version of "eachof" which I should have more clearly stated was a "bonus." A simple eachof designed as a drop-in replacement for the "for :" syntax would not raise any semantic issues different than "for :".
  
  

  
  Thanks for an interesting post.
  
  
  

• Re: eachof
  2003-10-01 03:57:29  anonymous2 [View]
  
  
  I struggle to swallow suns argument relating to the foreach keyword.
  Surely the loop syntax and method call syntax are significantly different as well as the context they are used in to allow existing code to live on.
  foreach() {...} and foreach(arg1,arg2);
  
  And to the "programmers" out there that thought it was a good idea to create a method called "foreach" in their source(apart from the obvious question why did you not call it forEach) didn't anyone tell you in programming 101 that mimicing your favorite(and usually previous) language was always the road to pains-ville.
  
  
  So I'll go along the foreach route and invent the "in" keyword for good measure
  imagine if you will, a world...
  
  foreach ( String name in nameCollection ) {
  System.out.println( name.length() );
  }
  
  Its java-tasic clean and intuitive, all as you'd expect in java world.
  
  And since this is my world I'd like to invent the following extra variable magic: "next" and "previous" also magically the correct types or null if your at either end of the collection.
  
  Sometimes you just have to take a hit on backwards compatibility and stop trying to be all things to all men.
  
  The article was very interesting and the eachof operator along with its bonus syntax is worth having anyday. To me using "eachof" or "in" makes no difference as long as it fits java world intuitiveness-ness and requires little thought.
  
  Don't be mistaken into thinking I'm against cryptic :'s in my code. I'm heavily in to perl and theres nothing I like more than a liberal sprinkling of ->'s and :: but that is a different world and has no place here...