[Grok-dev] meta class in megrok.resource?
trollfot at gmail.com
Fri Nov 20 06:07:43 EST 2009
I understand your point and I have no dogma in this.
We ca neasy restaure the thing how it was before.
The point of using the metaclass was simply to avoid grokking the
package simply to set a name
I'm very much in favor to simply use name = "". The use of grok.name
must be to "help and serve" not to constrain us.
Here, I felt the grokker was "way" too expensive just to set and attribute.
But, I did some work more yesterday that makes me feel like I did a
mistake on this
Trying to classProvides made me realize that this won't work, since
classProvides does not work with the subclasses.
Therefore, we'll have to directlyProvides(cls, ILibrary) in a grokker,
to make it work properly
2009/11/20 Martijn Faassen <faassen at startifact.com>:
> 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.
> Grok-dev mailing list
> Grok-dev at zope.org
More information about the Grok-dev