[Grok-dev] meta class in megrok.resource?

Martijn Faassen faassen at startifact.com
Fri Nov 20 04:11:51 EST 2009

Hi there,

hurry.resource needs a 'name' attribute to be present on an ILibrary 

The idea in megrok.resource is to make its Library class have this name 
attribute (not just instances of it), as it needs to provide the 
ILibrary interface. Note that it'd be the *class* providing an ILibrary 
interface, not the instance.

The simplest way for a class to get a name attribute would be to do this:

class Library(object):
     name = 'foo'

Unfortunately we want to use grok.name() instead.

In a previous implementation a Grokker was used to do this. Souheil in a 
checkin declared this operation as "WAY too expensive" and instead made 
the Library class derive from a meta class that takes care of setting 
the name business. I am wary of this as a metaclass introduces potential 
run-time complexity that a grokker doesn't.

One nice thing about grokkers is exactly that metaclass wizardy can be 
kept to a minimum. So I'd like to understand why a grokker is considered 
to be too expensive. After all, another grokker will grok Library anyway 
as it subclasses DirectoryResource. During run-time the expense is now 
larger (though still minimal).

If it's not desired to use a grokker, another option would be for 
hurry.resource.ResourceInclusion to try to adapt the incoming Library 
object to ILibrary first. The adapter could then do whatever it wants 
(and it could simply set '.name' in its __init__). The ILibrary 
interface is after all, really easy to satisfy (just a name is 
necessary). Though perhaps this option is a bit more complex as it'd be 
nicer to be able to directly let the Library class provide ILibrary, so 
taht the ILibraryUrl adapter can adapt the class.



More information about the Grok-dev mailing list