[PEAK] Re: PEAK digest, Vol 1 #674 - 3 msgs

[Phillip J. Eby]

At 09:17 AM 10/14/2005 -0700, Jay Parlar wrote:
> > Heck, generic functions make so many things easy that there's hardly any
> > need for anybody to have me write the frameworks any more.  Just use
> > generic functions and you don't need any frameworks.  :)
>
>Is that a hint as to what you were talking about in your "Self,
>version 2.0" post, regarding not needing an architecture? You *know*
>the (Python) world is waiting to hear more about that :)

It's a big part of it.  Dynamic variables, fact orientation, and monkey 
typing are too.  Very little that should be surprising to anybody that's 
been a long-time reader of this mailing list.  The only thing that's really 
new is that I'm now pretty certain I have an essentially-complete model 
that plugs all of the conceptual holes that exist in message-passing OO.

Essentially, fact orientation coupled with monkey typing more or less does 
for data what generic functions do for behavior.  The work I've been doing 
on the Chandler schema API lately, especially the new "annotation classes" 
feature has been a particular eye-opener.  It basically provides a clean 
approach to providing OO syntax sugar for a fact-oriented data model - 
monkey typing for data, basically, in the way that my previous monkey 
typing proposal is syntax sugar for a limited form of generic functions.

So, in essence I believe I now know how to transform the powerful, 
theory-complete concepts of fact orientation and generic functions into 
syntax-sugared stuff that looks like traditional Python OO, but doesn't 
have any of its limitations.

In practice, to do the syntax sugar *well* for anything but data, I'd need 
to be creating a new language, or at least a Python preprocessor.  But all 
of the capabilities should be implementable in Python anyway - generic 
functions were the hardest bit, languagewise.  Fact-orientation tools also 
can mostly be built as a library.