[Grace-core] Encoding classes

Kim Bruce kim at cs.pomona.edu
Fri Jul 15 16:53:52 PDT 2011


I think an important consequence of this more complex encoding is that the representations of classes have more complex types.  If all we are interested in are passing out objects that can be used to create more objects (i.e., objects that contain factory methods), then we can forget about all those duplicate methods contained in the encoding.  Essentially we would just be doing what Scala currently does in putting factory methods in the associated objects.

On the other hand, if we want them to be extensible (i.e., be able to create subclasses), then we need to make available the full type, which includes those duplicate methods for all the methods (protected and public) that are in the class.

Recall the syntax we are currently using for defining class C extending B:

class C implements CType {(...params...) -> extends B.new(...)
			var ...
			method ...
}

It is pretty clear that this syntax no longer leads to a truly compositional semantics any more as the method invocation B.new(...) alone does not provide all that we need from B to define C.  We can certainly hack the parser to grab B and not just B.new.  However it would be better to have a syntax that separated B from new.  Perhaps

class C extends B implements CType {(...params...) ->  with new(...)
			var ...
			method ...
}

or my favorite

class C(...params...) extends B(...) implements CType { 
			var ...
			method ...
}

The last is pretty similar to Scala.

We could still write
	C.new(...)
as before, though I'm not sure we would be able to treat C as an object as we did before.  That is, the semantics of classname.id would be different from object.id.

There would be no problem in packing constructors (factory methods) together into a simple object whose only job is to create new objects (as long as we don't try to extend the class using this).

Thus we could create
object CFactory {
	method new(...)-> CType { C.new(...)}
	...
}

That would work fine for contexts where all we needed to do was generate new objects of type CType.

If we really wanted to (and I'm not sure we or I do), we could create separate name spaces for classes and objects and automatically create a companion object for each class that contained all of its factory methods.

Lots of stuff to think about ...  I'm just sorry I didn't delve into this more much earlier.

Kim

P.S.  I'm giving a talk on Grace to an education group (the Liberal Arts CS Consortium) next Friday.  I'll be interested to see how they react to the language.


On Jul 15, 2011, at 4:11 PM, James Noble wrote:

> Argh. I meant to add: 
> 
> Good news: we can I think keep the class syntactic form even if we change the encoding. 
> 
> Good news: we can still use the encoding as a simple example of how classes work. 
> 
> I don't think this affects Grace programmers much either way. I think the most important things are if classes (factories) are objects, "new" is a method request, how generics work, and how / if classes subtend types.
> 
> J



More information about the Grace-core mailing list