I was rambling the other day about the relationships between the Iterator pattern and pretty much everything.  Eventually, I came up with a very strange insight, essentially I said that Iterator may be more fundamental than the tenets of Object Oriented programming (i.e. Identity, Inheritance and Encapsulation).  It just turns out, that someone has already thought about this before, and I'm actually pointing in the right direction!

E Rights, a project that has continually impressed me with its uncanny insight on the world of programming language design, writes about the fundamentals of the E language object model.  The E Language is not something new, in fact, if memory serves me correctly, a precursor of this language also named E, was possibly the first language that was written for the JVM (aside from Java of course).  It's just simply amazing that these guys have seem to get it right for all this time.  I'm right now on the verge of conversion!

The E language's object model is based on:

• Lambda Abstraction
• Message Dispatch
• Local Side Effects

I've read the above article several times in the past several years, however I didn't really get it.  In fact, there's still some stuff that hasn't sunk in yet.  However, my recent game with Iterators have given me a much better understanding of it.

Essentially what they're saying is that you've got functions now you can have functions defined inside functions; now the inner functions can use variables defined in the outer functions (the usual scoping rules); now the fact that these variables may be shared by many inner functions makes them in a way similar to member variable. 

Then they make the generalization that a function itself in really a degenerate form a bundle-of-methods.  Matter of fact, the recent article about C# delegates in Java makes the same observation.  Delegates are just degenerate version of annoymous inner classes, its no surprise that C# has plans on adding annonymous classes!    So these bundle-of-methods are like objects that contain methods.

So far that gives you constructs that give you member variables and methods.  The final addition of course is to add state. At this moment I don't fully grok their statements.

It just turns out that this definition of object orientedness has been around for 30 years:

We have found such lambda-based object definition to be simpler, more expressive, and more intuitive, than either of the common choices -- class-based and prototype-based object definition. The lambda-based technique for defining objects dates back at least to 1973 [Hewitt73], so we find it distressing that the other two are often assumed to be the only available choices.

Software archeology has paid dividends. Old things are new again!