[Grace-core] How to Program in Grace

[James Noble]

On 22/11/2012, at 13:44 PM, Andrew P. Black wrote:

> My pointy is that I didn't use to need any classes.  I'm forced to use classes just so that I can use them once to create the object that I first thought of, so that I can inherit from it.

I know.

>  Moreover, there is currently no way to make an abstract class (that is, a class that can't be instantiated) and inherit from that.

well there never has been in Grace - and so long as what you extend is (mostly) a first-class request, how could there be?


> You won't be surprised to learn that that's not how I see the problem at all!  I didn't have any difficulty with objects when I could inherit from them, and I didn't have any difficulty with their initialization.

no, I'm not surprised.  I was surprised about Kim's registration problem, although I shouldn't have been.


>> Of course another solution is to include the assertionTrait object as an instance variable rather than inheriting from it.  As we all know, inheritance is overused in OO languages.  Depending on how you are planning on using the assertionTrait object, that might be the best model anyway.  Certainly if you are applying it, it seems to be.  If you are adding other assertion methods, then you definitely would want it to be inherited.  Then with the current mechanisms, making it a class seems the best solution.
>> 
> 
> This is interesting.  What I'm going, in a sense, is "extending the language"; creating a "dialect" for writing test cases.

right!

>  I would like the user to be able to use assertEqual etc in that dialect, without having to say parent.assertEqual.  This is conventionally done using inheritance, but now that we have decided that dialects will be implemented using some sort of nesting mechanism, it may be that the right thing to use here is exactly that nesting mechanism.  I eagerly await to see how it will work!

me too!  I hope to send something out soon. again. 

> I need some time to think more about "Traits as Objects in Grace".  The key idea is that when using a trait, the client object gets to choose between making a new object (which will make new storage for any stateful methods) and using an existing object (which will induce sharing of any storage between clients).

So, my off-the-top-of-my-head,  "simple, obvious, and wrong" solution is:
 * no inherits keyword
 * "extends" keyword, only one permitted per constructor - applied to fresh object, it use the constructor to extend that fresh object (current semantics of "inherits") 
 * "includes" keyword, any number permitted - applied to a "stateful trait" (or potentially even an object) - extends a fresh object being produced by the constructor by the trait/object's contents

Hmm, OK, so that's neither simple nor obvious, is it?   Thus wrong. 

James' Next Law of Programming Language Design: It's easy to invent features; the trick is to keep most of them out! 

> James wrote:
> 
>> I had some idea flowing around in my head -  an assymetric  solution like Java ...
> 
> Maybe we are thinking along the same lines.  But I don't understand what's "one-and-a-half" about Java.  Java 1.5?

It's at least half a joke about how Java's design is asymmetric. 
Java often has one first-class thing, and then any number of second-class things.
One plus ∞ would be more accurate but less amusing!

 * you can extend one class, but implement many interfaces
 * you can dynamically dispatch on one argument, but statically dispatch on many
 * erased generics have one "real" component (the underlying raw type) and any number of erased types.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: chp%3A10.1007%2F978-3-642-03013-0_29.pdf
Type: application/pdf
Size: 152995 bytes
Desc: not available
URL: <https://mailhost.cecs.pdx.edu/mailman/private/grace-core/attachments/20121122/de07c48f/attachment-0001.pdf>