Couple important points here: 1. The JVM itself, along with a lot of methods in java.lang.* and java.lang.reflection.*, and even the javadoc tool, assume that any given class has 1 parent class, and 0-infinite interfaces. More generally, any given class has a strict list of parents where the top is always java.lang.Object, and implements any number of interfaces, which are technically almost always rendered as one flat list without any hierarchy.
It is therefore, as Jess Holle said, adding multiple inheritance is effectively impossible. Traits, on the other hand, with certain caveats, is easy. Which brings us back to the beginning of this thread, where more modest proposals extended either the interface keyword, or come up with a new one, but either way you'd have to 'implement' the trait/interface, not 'extend' it. I personally don't see a big difference between an interface and a trait and wouldn't mind overloading the 'interface' keyword for it. In fact, I don't really see them as different at all; I just consider the methods that have implementations as representing the default implementation. In my view, you can't have access to private/protected/ package private members of whatever implements you (somewhat unlike superclasses), and you can't have any state - no attributes, just methods, in other words. Maybe that rule can be relaxed a bit, but when arguing for them, I tend to prefer the no attributes, just methods rule - the prospect is scary enough as is for plenty of folk. On Nov 6, 1:35 pm, Jess Holle <[EMAIL PROTECTED]> wrote: > There are big limitations imposed by dynamic proxies here as I see it. > Dynamic proxies are beautiful interceptors for one or more interfaces, > but they themselves are of a synthetic class. > > If you have a class A and you want to mix-in/apply an interface to it, > dynamic proxies could help wire a default implementation around an > interface, but you'd still have to manually delegate to the proxy from > your class. Overall it still leaves a gaping "can't get there from > here" hole in the middle of things. > > John Nilsson wrote: > > I haven't done any benchmarking. But I can't imagine the overhead > > being "terrible", mesurable: yes, but I hear the reflection stuff in > > Java is rather quick. > > > If performance is a problem you could probably use some runtime class > > generation instead. But I imagine it would take a little more effort > > to assemble such a system. > > > BR, > > John > > > On Thu, Nov 6, 2008 at 8:20 PM, Casper Bang <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > But aren't dynproxies terribly slow? I thought that's why people > > dabble on invokedynamic. > > > /Casper > > > On Nov 6, 8:16 pm, "John Nilsson" <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > It shouldn't be to hard to implement traits as a library in > > current Java > > > using a dynamic proxy. > > > Should make for an interesting project. > > > > BR, > > > Jphn > > > > On Wed, Nov 5, 2008 at 3:00 AM, Mark Derricutt <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > Please please please bring on traits! I'm somewhat on the > > fence of rather > > > > seeing traits than closures in java sooner than the other. > > > > > I'm finding LOTS of places in my code where traits would just > > make things > > > > cleaner. > > > > > More and more I think I just want scala :) > > > > > On Wed, Nov 5, 2008 at 12:15 PM, hlovatt > > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > > > >> I thinks that Traits are a great idea for Java and judging by > > #215 the > > > >> posse, particularly Dick, like them. I wrote about them for > > Java 7 in: > > > > >>http://www.artima.com/weblogs/viewpost.jsp?thread=220916 > > > > >> What do you think? > > > > > -- > > > > "It is easier to optimize correct code than to correct > > optimized code." -- > > > > Bill Harlan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
