[E-Lang] pending revision of E in a Walnut

[Chris Hibbert]

>  The actual expansion is explained at 
> http://www.erights.org/elang/blocks/inheritance.html . 

One of the things that confuses me there is the use of adopt(). 
Apparently it's conventional, not built in.  But somehow the implementor
of BMaker is doing something that relies on AMaker's use of adopt(). 
What's the convention?  I didn't find it described anywhere.

I think there may also be something I'm not getting about the role of
Makers.  I have terms for many of the things that are thrown together
into classes.  (I'm sure I'm leaving things out, but) In Smalltalk,
classes are factories, provide shared behavior, host shared state, and
represent collections of instances.  In C++, they manage storage
allocation, and are where the type hierarchy was represented, but don't
allow access to instances.  Java they have most of these, but don't
manage storage, and don't exist at runtime.  I think they all have
shared behavior and shared state.

The one thing I can tell the Makers add is that they are able to vouch
that instances belong to them.  I haven't seen anything about storage,
presumably because E is built on top of Java.  They are pretty clearly
factories, and E doesn't have strict typing.  I guess one of the things
that makes them seem weird is that the maker's methods are top-level in
its definition, and instance methods are buried within one of the
clauses of the Maker.


> >> Second, I wonder whether there aren't security implications of treating
> >> the arguments to the constructor as instance variables.  Does this make it
> >> easy to forget to make copies of them?  Will this lead to subtle problems
> >> with wall-banging or other kinds of leakage, since the object the client
> >> supplied is known to be the one held by the object?
> >
> >I haven't seen a security issue with it. [...]
> 
> I am also failing to understand what you might be worried about here.  
> Please try again?

I'm new to the language, so bear with me.  I'm also not sure how to
answer (for myself) questions about security implications of language
features, so I have to ask.

In the languages I'm used to, the standard style is to make formal
parameters to a constructor have different names than the instance
variables.  This means that the constructor has to at least assign the
values to the instVars, if it doesn't actually build the instVars from
messages sent to the arguments.  In E, I noticed that the parameters
themselves are treated as initial state of the new object.  That seems
to mean, at a minimum, that the objects received as parameters are not
released as long as the object stays around, however the object wants to
compute its initial state from the values of its inputs.  Does that mean
that an inquisitive object could supply parameters that it can monitor
in more detail, and thereby tell, for instance, when the new object is
deallocated?  Even if the object didn't need to hold onto the parameter
object, but just wanted to retain some aspect of its value?  I can't
identify other potential holes, but it seems plausible that the fact
that the object is known to retain it's creation parameters throughout
its lifetime might enable objects using it to find out various things
about what happens over its lifetime.


Thanks for the explanation about your distinction between inheritance
(of implementation) and subtyping.  I guess I've treated the term
"inheritance" as including both parts.  Maybe this indicates that it's
worth being more explicit--I don't think my terminology is that unusual.
 And many OO languages conflate the two, so probably many OO programmers
aren't even aware of the distinction, and will have to think hard to see
that they are separable.


> >>  (Other than in the coordinate spaces code
> >> MarkM sent as part of a different discussion, but I haven't figured out
> >> how that works yet.)
> 
> Let's do lunch.

I'm planning to collect my questions on the various pieces of code I've
read (ebrowser, echat, and the coordinate space code you sent) and send
them to the list.  Let's do lunch after I've figured out what I'm
confused about.


Thanks to both of you!
Chris