[Grace-core] NS inheritance cannot work for grace

[Stefan Marr]

Hi:

I tried to read up a bit to be able to have an informed opinion on how to coerce SOMns into providing what you need.
But, after a while, I gave up. So, I don’t understand all the details, I am not even sure yet I get the subtle points of your examples.

To implement this efficiently, I think, Richards “wants” to take SOMns’ object model, or at least the instantiation part, apart and properly adapt it to your needs.
I suppose scoping etc are much easier to get right that way, and the resulting interpreter/object model code is hopefully a more direct representation of your spec. Which hopefully means it is going to be more maintainable in the long run.

Can it be implemented efficiently? I don’t see why not. The key here seems to be that you require to statically know the shape of the resulting object/class. To me this means the actual object factory can be created lazily on first use, and then be reused.


What I don’t really understand is where all the restrictions are supposed to be tested.

Inheritance is always done via the `inherit` keyword? (I suppose it is a keyword).

For the evil example, I don’t see an issue. It’s just that one would remember an object has a certain structure, and then error if that’s violated, right?

What I am not clear about is what’s a fresh object, and how to test for that?
Is that a property of the method? So, I can check method.objectFactoryInTailPosition == true?
I don’t see how this would work. Grace got late binding, right?

With respect to scoping, are there restrictions on where the inherit can appear in an object/class?
Is the expression after it restricted somehow?
I suppose that’s what Richard had problems with to properly map to Newspeak.
I guess the best solution would be just to change what SOMns does for Grace, because currently, the relevant expression for Newspeak’s superclass resolution is evaluated strictly outside of the object/class body.

Not sure this is of much help, for me, this might be better discussed via Skype so I can ask more questions…

Best regards
Stefan

> On 29 Nov 2017, at 09:10, kjx <kjx at ecs.vuw.ac.nz> wrote:
> 
>> A system where methods become inheritable or not based on the values of their arguments seems dubious to me.
> 
> :-) 
> 
>> (if I can override “random”, evil is no longer reliable). 
> 
> so I should've said I was assuming random here was a module.
> Although (modulo types & exceptions) it's not clear it matters what
> that expression does, so long as it returns a boolean.
> 
>>   def x = object {
>>       method p { object { } }
>>   }
>>   method parent(o) { o.p }
>>   object { inherit parent(x) }
> 
> perhaps. 
> arguably, at the top level of a module, this may well meet the definition of inheritable / manifest.
> If you can't override x or parent(_), why is this much worse than
> 
> object { inherit x.p } 
> 
> 
>> It also pushes the “cannot be overridden” criterion deeply through the entire potential call stack
> 
> not sure I follow this.
> 
>> Otherwise, yes.
> 
> Umm OK. 
> 
> James
> 

-- 
Stefan Marr
School of Computing, University of Kent
http://stefan-marr.de/research/