Replies inline. TL;DR: These features either (A) suck, (B) are coming in java 7 anyway, (C) aren't elegant, or (D) are nice, but not even remotely close to nice enough to accept the lack of tool support.
I loooove me some new JVM languages in the vein of java itself, but so far everyone and their uncle is making them, whereas I'd much rather see those interested in doing this all focussing on the same language (say, Phantom), and making it usable first. On Jul 27, 7:23 am, RogerV <[email protected]> wrote: > Stab has delegates and lambdas. In the lambda example it is > referencing a local variable that is in the outer scope of the method > containing the lambda expression. You can do the same thing in java lambdas, *IF* the local variable that's being referenced is final. If you do need a mutable local, then all hell is going to break loose when running the closure concurrently to the rest of the method. Therefore, java7 is in fact better at concurrency than stab already, if we look at just this part of it. See, this is what I mean with thinking things through. Java7's planned closures do not currently support accessing mutable outers (though its fine if the outer is _implicitly_ final, that is, nobody is modifying it, but it doesn't have a 'final' keyword associated with it) because that leads to confusing stuff. Does this compile in stab? If so, I posit the stab authors are taking silly shortcuts (replace my closure syntax with whatever syntax stab uses): Runnable[] runnables = new Runnable[3]; for (int i = 0; i < 3; i++) runnables[i] = #() {System.out.print(i);}; for (int i = 0; i < 3; i++) runnables[i].run(); If it does compile, stab sucks. That'll print '333' if it would be allowed to compile, which is exactly why it shouldn't be allowed to compile. There's a little middle ground in adding a lot of intelligence here (i.e. you CAN access mutables but NOT if some condition applies, such as "the variable was initialized in a for loop", or if tracking concurrency safety is done in the type system, in which case accessing mutables is fine if the closure is guaranteed to be limited to synchronous execution). > > The reason it achieve a high degree of Java interoperability is that > it doesn't try to be a strict CLR conforming C#, but instead a C# like > language that adheres to the types, class libraries, etc., of the JVM. > It's getter/setter feature generates Java Bean compliant methods. Just like Lombok. Which does work with virtually all java tools out there. > When writing > the APIs of a library that is intended to be easily consumable by > regular Java, then annotations can be used to sprinkle on checked > exceptions. There's a lot more to it than checked exceptions. Using annotations to fill every hole is not an elegant approach. > The implicitly typed variables are great for > reducing the boiler plate of type declarations involving the use of > generics. A problem java7 will also fix. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
