[Grace-core] Default methods

[Andrew P. Black]

On 8 Feb 2015, at 15:58, Kim Bruce <kim at cs.pomona.edu> wrote:

> 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.
> 
> 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.
> 

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.

I can see how to do this in minigrace, but other implementation strategies may make it harder.

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?) 

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.)


> If no one else is interested, then I’m happy to drop it as I would likely never use it.

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.

	Andrew

> 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).

Why would adding 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).

> 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.

I think that the Java VM doesn’t have a display to access the lexical scope.  So they have objects, and statics.

	Andrew


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20150208/571817e3/attachment.html>