Re: Meta-things

On 11/2/2002 16:42, Will Partain wrote:

> As ever, I think your instincts are 100% right, and so have
> no problems with the ideas at all.

Cheers.

> That said, it's not an itch that's particularly bothering me
> right now :-)

Heh. You can tell I'm not doing any real work at the moment from the fact
that all my top itches are blue-sky :-)
 
I've been playing with some ideas this afternoon and I've quickly bashed
together an Arusha-lite consisting of enough minidom stuff to be able to
read basic Arusha config files and a basic reimplementation of thing.py.

Here's what it does:

Imagine I have a meta-thing config file like so:

----- thing/test.xml -----
<thing name="test">

    <isRelevant>
        <param name="okstatus"> active </param>
        <code>
import string
return string.lower(self.status()) == okstatus
        </code>
    </isRelevant>

    <run_test>
        <param name="what"> World </param>
        <code>
print "Hello %s" % what
        </code>
    </run_test>

</thing>
----------

I can do as follows:

% python
Python 2.2 (#1, Jan 23 2002, 15:56:29)
[GCC 2.95.2 19991024 (release)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import thing
>>> testthing = thing.ArkThingsMgr().lookup('test')
>>> testthing
<thing.ArkThing object at 0x1f53d0>
>>> testthing.isRelevant
<thing.ArkField object at 0x1f0410>

At the moment this is pretty much like the normal scheme except that one
wouldn't normally lookup things of type thing. However, now we can run the
real magic:

>>> test = testthing.makeMetaThing()
>>> test
<module 'test' (built-in)>
>>> test.ArkTest
<class 'thing.ArkTest'>
>>> test.ArkTestsMgr
<class 'thing.ArkTestsMgr'>

The 'test' module and the ArkTest and ArkTestsMgr classes have been
dynamically constructed. ArkTest and ArkTestsMgr are subclasses of ArkThing
and ArkThingsMgr respectively. So given the following spec file:

----- test/foo.xml -----
<test name="foo">

    <status> active </status>

    <foo> bar </foo>
    
    <bar>
        <code>
self.run_test( what=self.foo() )
        </code>
    </bar>

</test>
----------

I can now instantiate a tests manager and lookup a test thing:

>>> foo = test.ArkTestsMgr().lookup('foo')
>>> foo
<thing.ArkTest object at 0x35cfd0>
>>> foo.status
<thing.ArkField object at 0x1d33b0>
>>> foo.status()
'active'

Now here's the real magic though, the ArkFields of the 'test' thing thing
have been promoted to first-class methods of the ArkTest class:

>>> foo.isRelevant
<bound method ArkTest.isRelevant of <thing.ArkTest object at 0x35cfd0>>
>>> foo.isRelevant()
1

The params of the fields are promoted to being keyword arguments of the
method:

>>> foo.isRelevant( okstatus='red' )
0

Hooking all this together we have:

>>> foo.bar()
Hello bar

which calls the ArkTest.run_test method, passing in the result of executing
the 'foo' ArkField. This method has been constructed from the 'run_test'
ArkField of the 'test' thing thing.

None of this looks that useful until you consider that now stuff like
'sidaiDeploy' can be ripped out of 'package.py' and put into a 'package.xml'
file in the sidai team instead; large monolithic methods can be broken up
into bits that can be overridden as necessary - such as the code setup
stuff; the magic #ark-site comments can be replaced with calls to empty
ArkThing methods that can be overridden.

Returning to your question Will:

> Would it be possible to try an implementation such that
> <thing>.xml and <thing>.py could co-exist (with the former
> taking precedence?)?  Then, we could be fairly leisurely
> about switching over from the one to the other.

I think it just might actually. The dynamically generated classes are
currently subclasses of ArkThingsMgr and ArkThing, but there's no reason
they couldn't be subclasses of the ones in <thing>.py (as long as they are
themselves subclasses of ArkThingsMgr and ArkThing), the field promotion
happens just like normal subclassing so a field can override a method of the
superclass.

I think it might be safer for me to branch the current arkbase before
attempting any of this though. There's a serious risk of deep breakage for a
long time.

Sorry for another long post. Code for the above is available if anyone wants
to have a look at it. It makes gratuitous use of Python 2.2 features though.

:-j

-- 
jonathan hogg, one good idea ltd, 131 queen margaret dr., glasgow g20 8pd
http://www.onegoodidea.com/ tel:+44-(0)7976-614338 fax:+44-(0)7970-537451