MOPs (warning: LONG)

[kosh]

On Thursday 23 October 2003 19:30, Joachim Durchholz wrote:
> - Dynamic fields
> Frankly, I don't understand why on earth one would want to have objects 
> with a variant set of fields. I could do the same easily by adding a 
> dictionary to the objects, and be done with it (and get the additional 
> benefit that the dictionary entries will never collide with a field name).
> Conflating the name spaces of field names and dictionary keys might 
> offer some syntactic advantages (callers don't need to differentiate 
> between static and dynamic fields), but I fail to imagine any good use 
> for this all... (which may, of course, be lack of imagination on my 
> side, so I'd be happy to see anybody explain a scenario that needs 
> exactly this - and then I'll try to see how this can be done without MOP 
> *g*).

From what I understand zope uses this extensively in how you do stuff with the 
ZODB. For example when rendering an object it looks for the closest callable 
item called index_html. This means you can add an object to a folder that is 
called index_html and is callable and it just works. I have a lot of objects 
where it is not defined in the code what variables they will have and at 
runtime these objects can be added. At least in python you can replace a 
method with a callable object and this is very useful to do.

Overall when working with zope I can't imagine not doing it that way. It saves 
a lot of time and it makes for very maintainable apps. You can view your 
program as being transparently persistent so you override methods with 
objects just like you normally would be inheriting from a class and then 
overriding methods in it. I really like using an OODB for apps and one of the 
interesting things is that you end up refactoring objects in your database 
just like you would normally refactor code and it is pretty much the same 
process.