<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;"><br><div><div>On 8 Feb 2015, at 15:58, Kim Bruce <<a href="mailto:kim@cs.pomona.edu">kim@cs.pomona.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div 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></div></blockquote><div><br></div>I do want the “built-in” classes to be extensible, but since in Grace these are defined in the standard prelude, rather than being truly “built in”, all that ought to mean is that the user needs to be able to provide an augmented standard prelude.</div><div><br></div><div>I can see how to do this in minigrace, but other implementation strategies may make it harder.</div><div><br></div><div>Another possibility is to provide away to parameterize the implementation so that the user can define what the factory methods are for String literals and Numeric literals (and even boolean literals?) </div><div><br></div><div>What makes this a challenge in Smalltalk is that it all has to work in the image that supports the compiler and the development environment. Things are much simpler in Grace because the compiler and the IDE are running in a world separate from the user’s program (except for any dialect checker.)<br><div><br></div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">If no one else is interested, then I’m happy to drop it as I would likely never use it.</div></div></div></blockquote><div><br></div>I don’t want to drop the requirement for users to be abel to customize the libraries. I do want to forget about adding methods to types.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Andrew</div><div><br></div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><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></div></blockquote><div><br></div>Why would <i>adding</i> something break existing code? Wouldn’t they just need a new name for the extended interface (which is what they did when they went form iterators to enumerations).</div><div><br></div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><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></div></blockquote><br></div><div>I think that the Java VM doesn’t have a display to access the lexical scope. So they have objects, and statics.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Andrew</div><div><br></div><br></body></html>