[Grace-core] Inheritance and Template Objects

[James Noble]

More comments...

> In these two respects, templates are just like types.   It may be that templates, like types, also need to be parameterized.


Yes, I think they would need to be. Parameterized by types, at least.
This is because types/type parameters are somewhat separate from objects.
(that's definitely something for another day)

>> The innovation is that an object carries its template around with it for the whole of its lifetime — just like a Java or Smalltalk object carries its class around with it.

yep - because a template is pretty much a class, isn't it?
As with any of the proposals I think we would have two things we have to distinguish:
the template syntax (template literal / declaration / constructor) 
and the template object that produces on evaluation.

>>  After an object has been created, we can ask it for its template, just as we can ask it for its type, thus: 

so this is a bit different from most of the other proposals, certainly most of the other class-like proposals --- we can get a class back from any object. It's like Tim's "constructor" proposal that you can extract them from an object.

> do you think of this as as base-level operation or a metal-level operation -
> i.e. when would people have to learn about templates (and "object") 

I am interested in this question in particular.

>> 		class aMatch.successful(b, m) {
>> 				inherits templateOf(true)

I don't think you've mentioned the class form yet: 
How does this class form relate to templates?
Class syntax has  "inherits" while template syntax as "uses"?

>> 				uses emptiness + enumerable 

So: this doesn't say "templateOf(emptiness)" because emptiness is already a template?
Is that right?   

Could we have def'ed emptiness as in an immediate object, and then had the same effect by saying "template(emptiness)" ?

and both these uses of template - I guess the point of being in a tempate expression rather than an object expression - is that there is some way for the "extra implicit" parameter of the identity of the newly constructed object that will ensure the templateOf(true), and the emptiness, and enumerable templates are executed / constructed as parts-to-be of the forthcoming successful match object?

(I note we have MI here; I still maintain this is orthogonal to the other issues - I think any of the proposals could have a trait-style composition algebra, or classical multiparent MI - again, I'd prefer not to talk about that yet, because we need to get the more basic bits of the mechanism done first.)

>> 	(1) 	The static typists will want to place restrictions on what templates can be used to create objects. 

> sure  the "noinal" types do the work here

"nominal" - the trait types anyway and the kind of static / stability restrictions we're talking about.

>> The difference is that aCartesianPoint.x(3)y(4) now answers a Point object rather than a template for a Point object, and consequently requesting x()y() on aCartesianPoint now prints the message 

can you request  anything from a template?
the trait algebra?
not instantiation, because that's done with the "object" apostrophe?

>> We can still inherit from the result of x()y(), but we now have to request its template; the resulting colorPoint objects will look the same both ways,

right..


>> but the side effects will be different.  

> 
How are they different?
Does that include the bindings of self during the Initialization code? the results of self requests (esp downcalls?) or not?

>> That is, without the template, creating a colorPoint will have the side effect of creating aCarteianPoint, printing  "this will be printed whenever x()y() is requested", taking its template, and then dropping the CartesianPoint on the floor.  This is the behavior that we want to eliminate.
> 
> so is the message printed in inheritance?  
> if so when / how
> i.e. when does the template initialisation run..

trying to understand the difference between inheriting from templates and objects

>> Explicit templates avoid James's "vampires": if James give me an encapsulated object, I can grab its template, but that does not help me to grab its data.
> 
> well we control templates the way we control mirrors...

this must allow access to data from  initialisation-time, surely

>> I might argue that this is bad style, and that anInterval should be a class, not a template, but there you are ... 

again, I'm not sure of the difference

>> Suppose that I decide to split the implementation of upward and downward intervals.  I can do this without forcing the client to refactor:

right..

>> Now the template that I get back from from()to()by(s) depends on the value of s, but since they both have the same template type, everyone should be happy.
>> 

but you can't inherit from it, because it's not static?

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20130404/902b7e67/attachment.html>