<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Yes, this is another Java patch. … and I agree that you are better off including all desired methods from the beginning. I’m not sure it would work poorly with structural types as the default methods are only allowed to access public methods of the class/object. However, it would certainly complicate the run-time.<div class=""><br class=""></div><div class="">I thought Andrew wanted to have something like “open classes/objects” so that methods could be added later to a class or object and all objects from libraries used could pick up that method as well.<div class=""><br class=""></div><div class="">If no one else is interested, then I’m happy to drop it as I would likely never use it..</div><div class=""><br class=""></div><div class="">This came up because I was reading about Java’s introduction of closures, and default methods are tangentially related (basically they wanted to add a “forEach” method to existing collection classes in a way that wouldn’t break existing code).</div><div class=""><br class=""></div><div class="">Interestingly, their closures can only access “essentially final” variables from the outer scope. I assume this restriction has to do with the poor implementation rather than anything we need to worry about.</div><div class=""><br class=""></div><div class="">This all came up because I’m lecturing on iterators in Java tomorrow in our data structures class and trying to add up-to-date material.</div><div class=""><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div class="">Kim</div><div class=""><br class=""></div></span><br class="Apple-interchange-newline">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Feb 8, 2015, at 3:38 PM, Andrew P. Black <<a href="mailto:black@cs.pdx.edu" class="">black@cs.pdx.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=windows-1252" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><div class="">On 8 Feb 2015, at 14:10, Kim Bruce <<a href="mailto:kim@cs.pomona.edu" class="">kim@cs.pomona.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite" class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Andrew,<div class=""><br class=""></div><div class="">Does something like Java 8’s default methods (methods added to a type rather than an implementation — and not allowed to refer to instance variables) satisfy your needs for extensible primitive types?</div><div class=""><br class=""></div><div class=""><font color="#4787ff" class=""><u class=""><a href="http://zeroturnaround.com/rebellabs/java-8-explained-default-methods/" class="">http://zeroturnaround.com/rebellabs/java-8-explained-default-methods/</a></u></font></div><div class=""><font color="#4787ff" class=""><u class=""><br class=""></u></font></div></div></blockquote><br class=""></div><div class="">I see default methods as one more patch made to cover-up a bad design decision made in 1994. </div><div class=""><br class=""></div><div class="">Like James said, I don’t see how they would work with implicit typing. In Java, when you say that an object satisfies and interface, it gets the additional methods, which must (presumably) be implemented in terms of the remainder of the interface. We never say explicitly that an object satisfies an interface.</div><div class=""><br class=""></div><div class="">I suppose that when Grace gets a “no-such-method” error on a receiver r, it could look at a list of default methods and see is there is one with the right name, and then see if its required methods are supplied by r — or by other dealt methods on r, recursively. This seems really arcane.</div><div class=""><br class=""></div><div class="">The right thing is to simply give the receiver the right method in the first place. And that’s pretty easy to do, I think.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Andrew</div><div class=""><br class=""></div><br class=""></div></div></blockquote></div><br class=""></div></div></body></html>