[PEAK] Interfaces

[Phillip J. Eby]

At 04:24 PM 6/28/2006 -0500, Terry Hancock wrote:
>Phillip J. Eby wrote:
>>  However, if you want a polished package like PyProtocols or
>>  zope.interface, there's nothing quite like that available yet.
>>  RuleDispatch is semi-beta but I'm redoing it because the
>>  implementation is too constrained to allow much new feature
>>  development.
>
>By the way, where do I find "RuleDispatch"?

svn co svn://svn.eby-sarna.com/svnroot/RuleDispatch

or

http://svn.eby-sarna.com/RuleDispatch


>Google just seems to find mailing list posts from you and Ian Bicking.

Really?  The top hit for RuleDispatch is a page that includes installation 
directions.  If I google "Rule Dispatch" instead, I get a "did you mean 
RuleDispatch?" prompt :)


>The universe sim part you describe is what Gabriel was
>working on (I'm going to forward your message to our list to see
>what he thinks of it). He wanted to use adapters, as I
>understand it, and has quite a custom thing going there
>with "dynamic components" which can be swapped out during
>game play. I don't fully understand it yet. He may love
>generic functions. I fully expect him to explode with
>frustration at the prospect of changing, though.

Well, an explosion with delight might be possible too.  The RuleDispatch 
engine lets you test arbitrary predicates, so you can have rules that only 
apply if a character is holding the magic amulet or whatever.  :)  See some 
stupid examples at:

http://dirtsimple.org/2004/11/retroactive-abstraction.html

There's also a presentation I gave at PyCon last year:

http://peak.telecommunity.com/PyCon05Talk/PyCon05Talk.html

And an IBM developerWorks article:

http://www-128.ibm.com/developerworks/library/l-cppeak2/


>Things are still sufficiently unformed, that I'm not entirely sure
>what I need where. I originally was thinking in terms of providing
>an interface to conform language modules to, but I think that
>in fact I'll be designing a custom locale-object factory, so I can
>do the checking within that (another factor is my concern that
>locale-writers will often be less-experienced programmers who
>may be put off by object-oriented programming in general, so
>it's better to ask them for well-defined functions and wrap
>the resulting locale module with my locale object).

Another possibility that I would consider is defining locales as a 
collection of...  well, rules.  This is the sort of thing that generic 
functions can do fairly well with the right wrapper code.  The rules' 
conditions and bodies would both be specified using Python code, but with 
the right API, you can make it look like a very high-level domain-specific 
language for locale specification.


>So far, I'm using interfaces to ensure conformance between
>different implementations of the internal language semantics
>object model (Sentence, Clause, VerbPhrase,
>NounPhrase, Verb, Noun, ... and other parts of speech).
>
>I found that if I tried to use just one object for these, that it
>created too many dependencies between modules, and it
>becomes impossible to write and test. So I need separate
>'test fixture' versions of each to do independent unit-testing:
>
>*parsing* -
>read localized input:
>"Drop the nails."
>and convert to internal concept model:
>[
><Clause: +
>V=<VerbPhrase: V=DROP A=()
>(IMP|+ THIRD #PLUR)>
>Ns=
><NounPhrase: N=NAIL a=()
>(ACC|- DEFIN #PLUR)>
> >]
>(I'm still working on readability, I'm afraid, but this
>__repr__ is just for debugging of course)

Just a comment -- pretty printing is a common use case for generic 
functions, especially if  you don't want to build complex representation 
code into the data types themselves.  You just define a pretty print 
function and add methods for the types you care about.


>*dereferencing* -
>convert expressions in internal concept model (above)
>to referents in universe model (e.g. which specific NAIL
>objects do you mean? What room are you in (and therefore
>what room container do they wind up in)? Did you have
>the NAIL objects to begin with?)
>
>This is actually very tricky.

I can imagine.  Although I'm not sure how it relates to interfaces as such.  :)


>Basically, I want to model just the part that each element needs
>as a separate test fixture. This is a way to get some degree
>of 'separation of concerns', because otherwise I have a big
>mess.

This type of problem pushes strongly in the direction of smart (i.e. 
generic) functions and dumb objects, because the operations tend to be 
complex, span multiple objects, and there are lots of different operations 
that have to be done.  So the primary separation of concerns is functional 
rather than type-based.


>And of course, I have a requirement to factor language-
>specific processing into a separate (and well-defined) module
>interface.

Or represent it in the form of rules, and then the "module interface" 
consists of having the module declare the rules it wants to have in effect.  :)