[Grace-core] How to Program in Grace

[Andrew P. Black]

On 21 Nov 2012, at 16:18 , James Noble wrote:

>> It seems to me that we know all of this stuff works fine for classes (either written as classes or object constructors)
> 
> Right - the current design works for classes, or "class like" objects. The catch is those singleton objects.
> I had some idea flowing around in my head -  an assymetric "one-and-a-half" solution like Java,
> distinguishing between classes that are "extended" - and traits or mixins that are "included" or something
> - classes maintain identity but traits/mixins don't - but the complexity seems to overwhelm any benefits
> 

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.  Moreover, there is currently no way to make an abstract class (that is, a class that can't be instantiated) and inherit from that.

> I'm not sure why converting those to classes doesn't work as well.  Can you give a more concrete example?

This is a concrete example.  The code is in .../NewOOL/GUnit/GUinit project/GUnit.grace,if you want to see it all.  The current file does compile. 

When an Object Factory needs to inherit, then I have to create an object-factory creator object.   At every point, I'm forced to use one more level of hierarchy than I used to need.

> It seems to me that we know all of this stuff works fine for classes (either written as classes or object constructors).  The difficulty is for objects.  The problem with those has to do with initialization code.  In fact if we had a class with only immutable features whose initialization does not depend on self, then we have no issues at all.  

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.

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

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

James wrote:

> I had some idea flowing around in my head -  an assymetric "one-and-a-half" 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?

	Andrew


	Andrew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailhost.cecs.pdx.edu/mailman/private/grace-core/attachments/20121121/6c1419c0/attachment-0001.html>