Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 8 Lambdas

datumedge.blogspot.co.uk

Post reply on HN
Print view View original

81–90 of 144 posts

Re: Java 8 Lambdas

#81

Post by mbel »

mccoyst wrote: post #71
mbel wrote: post #69

The idea of 'default methods' looks quite disturbing. It seems to allow implementation of some methods inside interfaces. Which is against the basic idea of interface, isn't it? Correct me if I'm wrong, but multiple inheritance problems form C++ are now going to be a brand new feature in Java.

There's no difference between implementing method dispatch with multiple inheritance versus multiple interfaces. What do you think C++'s multiple inheritance problems are? As long as Oracle doesn't add data members to interfaces, Java won't get any new problems.

I might be missing something, but what I see as a problem is a situation where: class C implements interfaces IA and IB, which both contain method doSomething() with default implementations, class C doesn't overrides this method, so which implementation is going to be called when method doSomething() will be invoked on instance of C? Will it behave the same way if it is called as instance of C and as instance of IA or IB? Clearly, there are rules in C++ to handle such situations, one may argue that they are problematic.

Re: Java 8 Lambdas

#83

Post by gouranga »

henrikschroder wrote: post #78
gouranga wrote: post #73

Earlier quoted context omitted.

Not necessarily. collection.Where(s => s.Property.Name == "Blah!").Single(); 4 hand grenades waiting to go off in that expression. Try and spot them. We have a 670kloc platform that doesn't have a single one in it (it's still .Net 2.0). 450 domain objects, 1000+ NH criteria queries and about 650 aspx pages...

It's sad that .Net doesn't have nullsafe properties, that would be a fantastic way to reduce boilerplate nullchecks everywhere.

Agreed! I think Anders Hejlsberg actually said that null handling in C# was one of his regrets but I can't find a reference to it anywhere.

Re: Java 8 Lambdas

#86

Post by peeters »

spullara wrote: post #19
zbowling wrote: post #5

I don't know how I feel about interface defaults. Why is that more important than say declared properties or unsigned types?

They are hugely important for introducing new behavior on existing interfaces without breaking compability. They are at the core of what is going to allow you to use all the new functional-style collection methods on your old collections without changing your implementation code at all. Declared properties and unsigned types are relatively small changes. BTW, in JDK8 they have provided limited support for unsigned ty…

> They are hugely important for introducing new behavior on existing interfaces without breaking compability.

That was bugging me too, thanks for the explanation.

My problem is the same was said for implementing Generics with type erasure. Doesn't make it a good feature for anyone starting a new project. I wish when they soiled the language for compatibility reasons that they would make it an "opt-in" feature.

As far as I can tell, interface defaults don't provide much value over compatibility.

Re: Java 8 Lambdas

#87

Post by spullara »

mbel wrote: post #81
mccoyst wrote: post #71

Earlier quoted context omitted.

There's no difference between implementing method dispatch with multiple inheritance versus multiple interfaces. What do you think C++'s multiple inheritance problems are? As long as Oracle doesn't add data members to interfaces, Java won't get any new problems.

I might be missing something, but what I see as a problem is a situation where: class C implements interfaces IA and IB, which both contain method doSomething() with default implementations, class C doesn't overrides this method, so which implementation is going to be called when method doSomething() will be invoked on instance of C? Will it behave the same way if it is called as instance of C and as instance of IA o…

If there is no way to break the ambiguity the compilation will fail and you will have to override that method (in 8.4.8.4 of the spec). You can use IA.super or IB.super to call one of the default methods if one of them works for you and you don't need your own bespoke implementation.

Re: Java 8 Lambdas

#88

Post by coopdog »

mbel wrote: post #81
mccoyst wrote: post #71

Earlier quoted context omitted.

There's no difference between implementing method dispatch with multiple inheritance versus multiple interfaces. What do you think C++'s multiple inheritance problems are? As long as Oracle doesn't add data members to interfaces, Java won't get any new problems.

I might be missing something, but what I see as a problem is a situation where: class C implements interfaces IA and IB, which both contain method doSomething() with default implementations, class C doesn't overrides this method, so which implementation is going to be called when method doSomething() will be invoked on instance of C? Will it behave the same way if it is called as instance of C and as instance of IA o…

If it's an interface you have to override the method.

An abstract class you don't, but you can only inherit one anyway.

Re: Java 8 Lambdas

#89

Post by mbel »

spullara wrote: post #87
mbel wrote: post #81

Earlier quoted context omitted.

I might be missing something, but what I see as a problem is a situation where: class C implements interfaces IA and IB, which both contain method doSomething() with default implementations, class C doesn't overrides this method, so which implementation is going to be called when method doSomething() will be invoked on instance of C? Will it behave the same way if it is called as instance of C and as instance of IA o…

If there is no way to break the ambiguity the compilation will fail and you will have to override that method (in 8.4.8.4 of the spec). You can use IA.super or IB.super to call one of the default methods if one of them works for you and you don't need your own bespoke implementation.

Thanks for clarifying; although I don't really like this feature, compilation failure seems to be the best solution (and well I guess I should have RTFM to begin with, sorry).

Re: Java 8 Lambdas

#90

Post by thomasz »

gouranga wrote: post #73
jmcqk6 wrote: post #63

Earlier quoted context omitted.

I think the implication here is that if they require fewer lines of code, they are going to reduce the number of bugs. Regarding LINQ: is there any .NET app out there that isn't using IEnumerable at some point? I can't recall every writing an app that didn't use it, unless it was an extremely simple app. Besides that, Lambdas are very useful in event subscription.

Not necessarily. collection.Where(s => s.Property.Name == "Blah!").Single(); 4 hand grenades waiting to go off in that expression. Try and spot them. We have a 670kloc platform that doesn't have a single one in it (it's still .Net 2.0). 450 domain objects, 1000+ NH criteria queries and about 650 aspx pages...

I don't see any pitfalls that wouldn't arise with imperative techniques. Well, Single() throws if there is no or more than one item with the property name "Blah!" in the collection, but if you just want the first one or none you should use FirstOrDefault() anyway. The point is that you need to write roughly a dozen lines with more room for hand grenades to reproduce that functionality with imperative constructs:

    Thing blah;
    bool found = false;
    foreach (var item in collection) {
        if (item.Property.Name == "Blah!") {
            if (!found) {
                found = true;
                blah = item;
            } else {
                throw new InvalidOperationException("collection contains more than one \"Blah!\" item!");
            }
        }
    }
    if (!found)
        throw new InvalidOperationException("collection does not contain a \"Blah\" item");
Come on, that's ridiculously verbose and doesn't solve any problems of the lambda version. If you are concerned about nulls, then you have to insert != null expressions anyway. And you can easily refactor by introducing an additional right above the old one,

    collection
        .Where(s => s != null && s.Property != null && s.Property.Name != null)
        .Where(s => s.Property.Name == "Blah!").Single()
while inserting the null checks into the imperative code takes considerably more effort (locating the predicate, making a decision weather or not to turn the predicate into a 120 char wide monster or adding another if block etc.)
Post reply on HN