Live data from Hacker News

Java 8 lambda syntax decided - same as C# and Scala

mail.openjdk.java.net

41–50 of 81 posts

Re: Java 8 lambda syntax decided - same as C# and Scala

#41
post #35

Earlier quoted context omitted.

What benefits does an empty try block give you? You can always use braces to separate a block without try at all.

> What benefits does an empty try block give you? An empty try block allows us to repeat variable declarations with the same name in a long stretch of scripty-style code. > You can always use braces to separate a block without try at all. You can use braces in Java, but not in that language I'm talking about: it'll throw an error saying "Ambiguous expression could be a parameterless closure expression, an isolated op…

> An empty try block allows us to repeat variable declarations with the same name in a long stretch of scripty-style code.

Either I'm missing something here, or this is really as bad as it sounds.

I understand you want nested scopes that end before the method's scope ends, but cannot for the life of me think of a defensible code example. Why not just make them into methods?

Re: Java 8 lambda syntax decided - same as C# and Scala

#42
post #25

Nice to see pragmatism playing a role here. A big problem with Java has always been the "design by committee" nature of it where we end up with some theoretical best case that satisfies everyone's egos but turns out to utterly suck when used in practice. From another point of view ... it's a shame we needed so many years to come up with "let's do it like C#".

It's also a shame they haven't done so with other features -- like getting rid of checked exceptions.

Re: Java 8 lambda syntax decided - same as C# and Scala

#43
post #35

Earlier quoted context omitted.

> What benefits does an empty try block give you? An empty try block allows us to repeat variable declarations with the same name in a long stretch of scripty-style code. > You can always use braces to separate a block without try at all. You can use braces in Java, but not in that language I'm talking about: it'll throw an error saying "Ambiguous expression could be a parameterless closure expression, an isolated op…

> An empty try block allows us to repeat variable declarations with the same name in a long stretch of scripty-style code. Either I'm missing something here, or this is really as bad as it sounds. I understand you want nested scopes that end before the method's scope ends, but cannot for the life of me think of a defensible code example. Why not just make them into methods?

In C++ block is often a way to ensure automatic variable destruction. This is important, because in C++ often there is important stuff going on in destructor. For example in RAII idiom.

Example:

   ...
   ...
   
   { //critical section
     QMutexLocker locksInConstructorAndUnlocksInDestructor(&mutex);
     a = doStuff(a,b,c);
     b = doOtherStuff(a,b,c);
     c = andAnother(a,b,c);

   }
   
   ..
   .. 
It would be overkill to make this block a function, especially when code in critical section changes many variables.

Re: Java 8 lambda syntax decided - same as C# and Scala

#44
post #35

Earlier quoted context omitted.

> What benefits does an empty try block give you? An empty try block allows us to repeat variable declarations with the same name in a long stretch of scripty-style code. > You can always use braces to separate a block without try at all. You can use braces in Java, but not in that language I'm talking about: it'll throw an error saying "Ambiguous expression could be a parameterless closure expression, an isolated op…

> An empty try block allows us to repeat variable declarations with the same name in a long stretch of scripty-style code. Either I'm missing something here, or this is really as bad as it sounds. I understand you want nested scopes that end before the method's scope ends, but cannot for the life of me think of a defensible code example. Why not just make them into methods?

And why not pick java simpler nested scope syntax '{ //doit }'?

Re: Java 8 lambda syntax decided - same as C# and Scala

#45
post #25

Nice to see pragmatism playing a role here. A big problem with Java has always been the "design by committee" nature of it where we end up with some theoretical best case that satisfies everyone's egos but turns out to utterly suck when used in practice. From another point of view ... it's a shame we needed so many years to come up with "let's do it like C#".

It's also a shame they haven't done so with other features -- like getting rid of checked exceptions.

Getting rid of something is always harder than adding it later.

Re: Java 8 lambda syntax decided - same as C# and Scala

#46
post #25

Nice to see pragmatism playing a role here. A big problem with Java has always been the "design by committee" nature of it where we end up with some theoretical best case that satisfies everyone's egos but turns out to utterly suck when used in practice. From another point of view ... it's a shame we needed so many years to come up with "let's do it like C#".

It's also a shame they haven't done so with other features -- like getting rid of checked exceptions.

Can you expand on why would you like to get rid of checked exceptions?

Re: Java 8 lambda syntax decided - same as C# and Scala

#47

Earlier quoted context omitted.

It's also a shame they haven't done so with other features -- like getting rid of checked exceptions.

Getting rid of something is always harder than adding it later.

I don't think this is the case here. The question isn't whether you "add" or "remove" something. The question is whether the old programs will still work or not.

If I understand checked exceptions correctly, removing them will only allow more programs to compile. The old ones will still be valid as their (now optional) try-catch/finally blocks won't go anywhere.

Re: Java 8 lambda syntax decided - same as C# and Scala

#48
post #25

Nice to see pragmatism playing a role here. A big problem with Java has always been the "design by committee" nature of it where we end up with some theoretical best case that satisfies everyone's egos but turns out to utterly suck when used in practice. From another point of view ... it's a shame we needed so many years to come up with "let's do it like C#".

It's also a shame they haven't done so with other features -- like getting rid of checked exceptions.

Some people like them, you know.

Re: Java 8 lambda syntax decided - same as C# and Scala

#49
post #25

Nice to see pragmatism playing a role here. A big problem with Java has always been the "design by committee" nature of it where we end up with some theoretical best case that satisfies everyone's egos but turns out to utterly suck when used in practice. From another point of view ... it's a shame we needed so many years to come up with "let's do it like C#".

It's also a shame they haven't done so with other features -- like getting rid of checked exceptions.

At least Java 7 has multi-catch, i.e.

  catch (FirstException | SecondException ex)

Re: Java 8 lambda syntax decided - same as C# and Scala

#50
post #35

Earlier quoted context omitted.

> What benefits does an empty try block give you? An empty try block allows us to repeat variable declarations with the same name in a long stretch of scripty-style code. > You can always use braces to separate a block without try at all. You can use braces in Java, but not in that language I'm talking about: it'll throw an error saying "Ambiguous expression could be a parameterless closure expression, an isolated op…

> An empty try block allows us to repeat variable declarations with the same name in a long stretch of scripty-style code. Either I'm missing something here, or this is really as bad as it sounds. I understand you want nested scopes that end before the method's scope ends, but cannot for the life of me think of a defensible code example. Why not just make them into methods?

I did say scripty code. My typical scripting session from scratch starts with opening a simple editor and starting to type in code. The structure is loose, perhaps it's testing something I've written in another file in a statically-typed language. As the code evolves, I slowly give it more structure by reworking it. At some stage I MIGHT put some code into methods.

But before that stage, nested scopes are useful because I'm far less likely to pass the wrongly-named variable into a function when I'm cutting and pasting code. An example coding snippet...

    def out= new File("blah")
    try{
      def testdata= "abcdefg"
      def result= SomethingToTest(testdata, out)
      assert result == result.getSth()
    }
    try{
      def testdata= "hijk"
      try{
        def result= SomethingToTest(testdata, out)
        assert result == result.getSth()
      }
      try{
        def result= SomethingToTest(testdata)
        assert result == result.getSth()
      }
    }
If I use testdata1, testdata2, result1, result2, etc, I might forget to rename a variable after cutting and pasting, and think a test works when it doesn't.
Post reply on HN