Daniel Sjöblom said:
Certainly welcome. But IIRC, the casts are still there in the bytecode.
Surely this could have been implemented without casts?
As I read through the specs, I noticed that their intention was not to
change the JVM too much, instead force the compiler to produce existing
bytecode for new constructs/features. But to be honest, I do not know the
relation between Java code and the Java VM (which executes bytecode).
Not very useful in my opinion. I'd rather see the java APIs taking more
advantage of the iterator concept. So, just put a forEach(Iterator,
Function) method in Collections instead. Oh, and give me first class
functions instead of lame syntactic sugar
IMO they are useful, because the intention is much clearer. Coding a for
loop using explicit iterators is tedious.
Again, IMO, I would have preferred other iterators. Iterators like they are
used in STL (C++). There is no special for-loop but the way to go about that
is (pseudo-code):
tyepedef std::vector< std::string > stringVector;
stringVector sv; /*...*/
for( stringVector::iterator iter = sv.begin(); iter != sv.end();
++iter )
{
// iter points to current element in vector
// *iter is a reference to the current object
}
But I guess that is a matter of style. The algorithm-header defines a
template function 'foreach' which allows executing a function for each
element in the collection.
[...]
One feature that you
didn't mention is variable arguments. Moderately useful I guess, but the
rationale for this, implementing printf, is rather weak.
Indeed moderately useful, and a chance to introduce bugs that can't be
checked at compile time. This seems like a feature that is targeted towards
new Java developers that have C++ knowledge.