Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (115)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 3 [4] 5
  ignore  |  Print  
  Java Lambdas Finalised!  (Read 13588 times)
0 Members and 1 Guest are viewing this topic.
Offline Gudradain
« Reply #90 - Posted 2011-12-14 06:40:54 »

As I stated before, creating an abstract class is impossible in the case where an interface is being properly used.  Interfaces are, by design, for dealing with cross-cuts of the inheritance hierarchy.  So what you are suggesting is doesn't work. 
It is possible to create an abstract class implementing some methods of an interface, what is wrong with that? If you really need multiple inheritance, maybe it means that something is wrong in the design of your whole source code, Java doesn't need this feature as it should not handle any crappy choice with crappy solutions. An interface should not contain any implementation of method.

Ah, the joy of arguing with Julien. His opinions are set in stone, just like all the APIs he uses. I admire his ability to write the perfect API at first attempt. For us mere mortals, I find this a positive and sensible move!

Sorry but on this one I'm with Julien. I agree that interface should not contain any code. Usually when a class implements an interface you expect the implemented methods to behave in a certain way based on the definition of the interface. If you have 2 conflicting interface like OrangyTang said you have no idea what the implemented methods are doing.

Seriously what is too difficult in doing the following to get similar behavior to multiple inheritance if that is what you want :

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
public class A{
    public void methodA(){...}
}
public class B{
    public void methodB(){...}
}
public class newA extends A{
...
}
public class newB extends B{
...
}
public class C{
    public final newA;
    public final newB;
}


Or you have the alternative to create two interface for class A and B, make C implements those interface and just redirect the method to newA and newB variable.
Offline nsigma
« Reply #91 - Posted 2011-12-14 09:56:38 »

If you have 2 conflicting interface like OrangyTang said you have no idea what the implemented methods are doing.

Really?  That's not my reading of the spec.  Indeed, OrangyTang later states it's not ambiguous (though to be fair he does call it ugly)

Seriously what is too difficult in doing the following to get similar behavior to multiple inheritance if that is what you want :

Extending interfaces is not about multiple inheritance.  If I never, ever, ever see the MyInterface, MyInterface2, MyInterface3 pattern again it will be too soon!  Smiley

Sorry but on this one I'm with Julien. I agree that interface should not contain any code. Usually when a class implements an interface you expect the implemented methods to behave in a certain way based on the definition of the interface.

As I stated before, creating an abstract class is impossible in the case where an interface is being properly used.  Interfaces are, by design, for dealing with cross-cuts of the inheritance hierarchy.  So what you are suggesting is doesn't work. 

Roquen is right.  I have no problem with interfaces containing (default) code.  The key thing, and why this is still Java, these aren't abstract classes and this isn't multiple inheritance is that interfaces still do not contain state.

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline OverKill

Junior Member




Java games rock!


« Reply #92 - Posted 2011-12-14 10:00:38 »

...
Seriously what is too difficult in doing the following to get similar behavior to multiple inheritance if that is what you want :
...
Whow, hold yer horsis. What gives you the impression developers of today actually want to write code?
Majical one-liners FTW!
</sarcasm>
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #93 - Posted 2011-12-14 10:06:58 »

If you have 2 conflicting interface like OrangyTang said you have no idea what the implemented methods are doing.

Really?  That's not my reading of the spec.  Indeed, OrangyTang later states it's not ambiguous (though to be fair he does call it ugly)

I think it's probably important to distinguish between strictly-unambiguous (in the sense that it's well defined in the spec that my example code throws a compiler error), and apparently-ambiguous (in the sense that a human reader can't immediately and easily see exactly what will be called without trawling through lots of code).

Obviously what's "apparently ambiguous" will vary from person to person, but I think default implementations are probably too far for most people's definition. My personal gripe with it is that it breaks the locality of the code - if you see 'implements FooInterface' then you *know* that it conforms to an external interface, but the implementation is entirely within this single code file. Default implementations break that so now you've potentially got to be switching between multiple files all the time to see what's *actually* going on.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #94 - Posted 2011-12-14 11:25:28 »

I thought that yer typical default implementation was supposed to do something totally benign like output a debug message  or throw an exception or something - isn't the idea that it's there just so you can extend interfaces in libraries with new stuff, that existing code doesn't know about and therefore will never call? So really your default implementations should more or less all just return null / 0 / throw new RuntimeException("Not implemented") etc.

Cas Smiley

Offline gouessej
« Reply #95 - Posted 2011-12-14 13:36:39 »

Ah, the joy of arguing with Julien. His opinions are set in stone, just like all the APIs he uses. I admire his ability to write the perfect API at first attempt. For us mere mortals, I find this a positive and sensible move!
You prefer caricaturating my comments especially when I disagree with you.

My opinions are not set in stone. For example, my first attempt of writing a first person shooter was written in C++ until I discovered Java could do the same job more easily. In 2006, I didn't want to use any scenegraph whereas I have used 2 of them these last 3 years. I didn't want to use OpenAL to avoid adding another native dependency to my project whereas I now use JOAL. You're completely wrong.

The APIs I use are not set in stone neither. JOGL 1.1.1a and JOGL 2.0 are noticeably different, porting several renderers was not completely trivial. JMonkeyEngine and Ardor3D have evolved last years.

Have you often worked with students? I'm sure they are mortals like me and this use of the "default" keyword in interfaces won't ease the task of explaining to them what a Java interface is and what it is for. I still think that the syntax of Java should be frozen even though it is not perfect because some attempts of improving it might be lethal for it by driving it too much complicated and that is what happened to C++. Maybe lambdas are helpful but this possibility of putting a default implementation of some methods in interfaces is not the way to go in my humble opinion.

I find your argument particularily weak, you laught about me because I refuse a change. Something shown as "modern" is sometimes neither fair nor good, it does not mean that I refuse any change, I just refuse accepting them blindly. This is the same in politics: If homophobia and the death penalty were "modern", I would still fight against them whatever people think about them.

Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #96 - Posted 2011-12-14 13:49:26 »

I'm on the fence with the whole interface thing myself. The more I look at it the more it basically seems like what Java needed was just plain old multiple inheritance and ditching interfaces completely, which appear to be basically a degenerate form of multiple inheritance.

Cas Smiley

Offline Roquen
« Reply #97 - Posted 2011-12-14 17:04:34 »

Quote
Have you often worked with students? I'm sure they are mortals like me and this use of the "default" keyword in interfaces won't ease the task of explaining to them what a Java interface is and what it is for.
Here's the deal. "IF" an abstract base class can perform the same job, then it is the superior choice IMHO. But the point here is that it isn't always a option.  Examples include cross-cuts, as I've already mentioned, backward compatibility and avoiding special casing of other library code. Unfortunately (again IMHO) Java culture encourages overuse of interfaces when it is unnecessary. (As an example see section "12. Unintended consequences for the language" of the spec).

@Gudradain: Like Julien's abstract base class suggestion, this does not address the issue at hand.  And like abstract base classes, if a composite class can do the job, great, but it still doesn't address the issues at hand.

Quote
The more I look at it the more it basically seems like what Java needed was just plain old multiple inheritance and ditching interfaces completely, which appear to be basically a degenerate form of multiple inheritance.
Cringe!!!  This is completely different from MI, like nsigma said: "that interfaces still do not contain state".  As stated in the spec, this is more like adding lightweight taits/mixins to the language.

Quote
I thought that yer typical default implementation was supposed to do something totally benign like output a debug message or throw an exception or something -
It could be used in this manner, but I think that it would be pretty uncommon.

Quote
isn't the idea that it's there just so you can extend interfaces in libraries with new stuff, that existing code doesn't know about and therefore will never call?
Yes backward compatibility is one the the big reasons.  Although "new" code most likely will be called, but in a transparent way the the user doesn't care about.  I'd image that one of the big internal (JDK group) pushes for this is to allow using of lambdas in classpath classes.

BUT another reason is to get rid of some pointless boilerplate in code (something that has not been discusses at all in this thread).  Oh yeah, java programmers seem to love their pointless boilerplate code...sigh.  Exactly the kinds of things that can be done is still unclear since the spec isn't finalized.
Offline Gudradain
« Reply #98 - Posted 2011-12-14 18:36:50 »

complexity VS boiler plate code  Cranky
Offline JL235

JGO Coder


Medals: 10



« Reply #99 - Posted 2011-12-14 18:38:51 »

I don't believe the solution is to allow interfaces to include behaviour code, that defeats the point of an interface, and we have abstract classes for that. Multiple inheritance is also not the solution.

Personally I believe you need mixins, or something similar, to solve this issue.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #100 - Posted 2011-12-14 19:05:34 »

I never really did see what was wrong with multiple inheritance. I've got a bunch of code in several different places... why can't I compose them all into one class? Interfaces have always been useless degenerate contracts - just a bunch of method signatures and a "name".

Cas Smiley

Offline Gudradain
« Reply #101 - Posted 2011-12-14 19:09:30 »

I never really did see what was wrong with multiple inheritance. I've got a bunch of code in several different places... why can't I compose them all into one class? Interfaces have always been useless degenerate contracts - just a bunch of method signatures and a "name".

Cas Smiley

The problem I always saw with multiple inheritance is variable with same name. What happen when you inherit a lot of variable from 2 or more class and many of them have the same name?
Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #102 - Posted 2011-12-14 19:12:52 »

I always thought that the simple answer would be to alias any conflicts, or be explicit. Much like the hackery in the new default interface conflict stuff in Java now.

Cas Smiley

Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #103 - Posted 2011-12-14 19:14:41 »

Actually looking at mixins, yes, that's probably more like what I'd like to see.

Cas Smiley

Offline JL235

JGO Coder


Medals: 10



« Reply #104 - Posted 2011-12-14 21:21:00 »

I'd also go further, and say that it should be impossible to expose fields and private methods outside of a class. If a subclass or mixin were to define a private method or field with the same name, then it would be a separate field or method. So both a super and sub-class can both have the field 'foo', with no issues with them conflicting (since each has their own 'foo').

That way the only place conflicts and overriding behaviour can occur is around exposed method signatures, and so helps to avoid unexpected behaviour.

Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #105 - Posted 2011-12-14 22:13:11 »

Isn't that already the case?

Cas Smiley

Offline JL235

JGO Coder


Medals: 10



« Reply #106 - Posted 2011-12-14 23:16:16 »

Yeah your right, I had the idea that you could override a class and make fields become protected or public, like with methods.

Learn something new every day!

Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #107 - Posted 2011-12-14 23:50:08 »

I don't even think you can make a private method less private either.

Cas Smiley

Offline sproingie

JGO Kernel


Medals: 202



« Reply #108 - Posted 2011-12-15 00:30:34 »

Whether default-public or default-private is a better idea, I can't say, but java certainly made a pretty damn odd choice with the default.

And BTW, you can't make a private method public by overriding it.  You're just defining an entirely different method.  Try attaching @Override and see what happens.

Offline Roquen
« Reply #109 - Posted 2011-12-15 16:04:56 »

So basically you kids that think this is a bad idea subscribe to the: "All public interfaces, once released, shall have a fixed set of methods forever and ever, AMEN!" notion?  This seems to me to add way more complexity than a trivial default method decl.

Since I'm lazy, I just grabbed a trival example from someone's blog and sliced-and-diced it:

Today's reversing some instance of the List interface with the Collections helper class.
1  
2  
3  
  List list;
  //...
 Collections.reverse(list);


The massively complex addition needed for integrating 'reverse' into List:
1  
2  
3  
4  
5  
6  
7  
8  
public interface List extends Collection
{
  // all the current method defs in List
 ...

  // Yikes, this is mind numbing!
 extension void reverse() default Collections.reverse;
}


With this addition, every class in the whole-wide-world which implements "List" still auto-magically works.  Yea!  Now we can instead write:
1  
2  
3  
  List list;
  //...
 list.reverse();


Which, if you're being honest, you'll have to admit is much cleaner looking than calling a static method in a utility class.  But that's simply an added bonus.  The routines in Collections know nothing about the implementation details of the given concrete class.  Therefore they have to "perform the operation in the stupidest way possible (tm)".   But now any class which implements List can override the reverse method and it just auto-magically works (tm). Progress!

So now, joe-average/student programmer don't even need to know about the existence of the "Collections" helper class.  All they need to know is that List has a 'reverse' method and the rest is merely an implementation detail.

For non-joe-average programmer, life is better as well.  The only way to work around this issue is a huge mess of 'instanceof' nonsense.  How is that less complex?  And compared to convariant overrides, this should be a walk in the park.

All of the above is again trivial.  Interesting usages remain to be seen and depend on the final spec and how it interops with lambdas.
Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #110 - Posted 2011-12-15 18:31:04 »

I foresee some exceptionally devious usage of static classes to start bunging state into interfaces....

Cas Smiley

Offline nsigma
« Reply #111 - Posted 2011-12-15 18:35:02 »

I foresee some exceptionally devious usage of static classes to start bunging state into interfaces....

Just because I have knives in my kitchen doesn't mean I stab myself in the face with them every night ... which is not to say there aren't a few nutters in the world!  Wink

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #112 - Posted 2011-12-15 19:06:15 »

Just like riding motorcycles... the problem is quite often other people...

Cas Smiley

Offline Roquen
« Reply #113 - Posted 2011-12-15 20:22:54 »

The only vector of "trickery" that comes to mind is having multiple sets of util classes with differing static methods which are used as default methods for some set of interfaces.  Then using multiple classloaders for mixing-in a chosen grouping of methods.  But this not really new, the only potential "advantage" is that (depending on how VM ends up performing the injection) is that the created multiple versions of a given concrete class (with a specific fully qualified name) will potentially be insured to be binary compatible.
Offline BoBear2681

JGO Coder


Medals: 18



« Reply #114 - Posted 2011-12-15 20:32:29 »

Just like riding motorcycles... the problem is quite often other people...

I was taught to be careful while driving, because "everybody on the road is an idiot except you."  Does the same thing apply to programming?
Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #115 - Posted 2011-12-15 20:40:20 »

Just like riding motorcycles... the problem is quite often other people...

I was taught to be careful while driving, because "everybody on the road is an idiot except you."  Does the same thing apply to programming?
It certainly does. If you're writing library code that is.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #116 - Posted 2011-12-15 20:50:35 »

Just like riding motorcycles... the problem is quite often other people...

I was taught to be careful while driving, because "everybody on the road is an idiot except you."  Does the same thing apply to programming?

When programming, everyone is an idiot, *including* me.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline ra4king

JGO Kernel


Medals: 346
Projects: 3
Exp: 5 years


I'm the King!


« Reply #117 - Posted 2011-12-15 21:54:03 »

Just like riding motorcycles... the problem is quite often other people...

I was taught to be careful while driving, because "everybody on the road is an idiot except you."  Does the same thing apply to programming?

When programming, everyone is an idiot, *including* me.
LOL!

Fact: everybody is an idiot except you Grin

Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #118 - Posted 2011-12-15 22:19:39 »

Damn that tag.

Cas Smiley

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 799
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #119 - Posted 2011-12-15 22:29:19 »

Damn that tag.
Err, I must have screwed up, I was under the impression it was disabled in posts.

Anyway, I completely got rid of the [you]-code a few seconds ago.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Pages: 1 2 3 [4] 5
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

radar3301 (11 views)
2014-09-21 23:33:17

BurntPizza (28 views)
2014-09-21 02:42:18

BurntPizza (19 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (27 views)
2014-09-20 20:14:06

BurntPizza (30 views)
2014-09-19 03:14:18

Dwinin (47 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (102 views)
2014-09-10 06:39:09

Tekkerue (50 views)
2014-09-09 02:24:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!