[Cubicweb] About CubicWeb >= 3.7 (potential) refactorings
aurelien.campeas at logilab.fr
Thu Feb 11 14:06:00 CET 2010
Le jeudi 11 février 2010 à 13:39 +0100, Sylvain Thénault a écrit :
> > > Introduce an ORM to cleanup Entity class (:eid:`615240`)
> > > ========================================================
> > > We'll have to do this at some point. Was expected in 3.6 but... That doesn't
> > > seems that in a hurry though.
> > >
> > an ORM ... do you actually mean a specific namespace for methods ?
> I mean a class responsible to handle the logic behind attributes/relations
> descriptors, as well as thing such as fetch_rql, unrelated, and so on...
> > > Introduce adapters to cleanup AnyEntity and other type specific classes
> > > (:eid:`482289`)
> > > =======================================================================================
> > > To finally cleanup the entity classes namespace. Would avoid mixins trick
> > > (use case: turn the TreeMixIn into a base adapter). Finally, allows to
> > > provide much more clear / reusable code.
> > >
> > > Check:
> > >
> > > * how does it fit with our 'proximity' computation in the implements selector?
> > We should begin, I feel, to explain what an adapter is, and what problem
> > it solves. Same for ZCA (the litterature on ZCA I have read 'till now is
> > not cristal clear).
> > For namespaces/registries, we already have the vregistry thing. Isn't
> > ZCA another way to provide the same kind of service ?
> there is definitly overlapping. We should first have an idea about how
> we want this to work.
> To make thinks clearer, when I talk about using ZCA, I'm talking about:
> * more Interfaces
> * adapters, able to turn an interface into another one
example of turning an interface into another one ?
> I don't feel like we'll be able to use the zca's provided adapters registry,
> but that we will probably need an in-house vregistry based implementation.
> > If Entity namespace pollution is the main pb. to solve, couldn't reusing
> > the vregistry be a solution ? (as in: it would host Entity methods)
> > But the score-based dispatch used there maye not be fit.
> I don't get it.
which part ?
> > What about simple generic functions ? We could write things like:
> > from cubicweb.entity import dc_title
> > @dc_title.method(Fooentity)
> > def dc_title(entity):
> > return entity.name
> > Here dc_title has been turned into a lightweight dispatcher object that
> > needs not to live in a global registry but in plain python modules. In
> > the example above we just added a concrete implementation that applies
> > to subclasses of Fooentity.
> > Reusing existing gf libs, one would get multiple dispatch as a
> > (worthwhile) bonus.
> > Another silly example:
> > from cubicweb.entity import dc_description, printable_value
> > from cubicweb.schema import eschema
> > @dc_description.method(Fooentity, basestring)
> > def dc_description(entity, format='text/plain')
> > if 'description' in eschema(entity).subjrels:
> > return printable_value(entity, 'description', format=format)
> > return u''
> > I hope you get the idea ...
> I get it, but imo adapters acheive the same goal and keep oop style
> programming, while with generic function you get down to, herr, functions.
Well, that's a really big plus in my book, because functions rock (and
they are all over the place in oop just under the plain "method" name)
and generic functions definitions need not be set under a Class
namespace to work (hence avoiding one form of object ns pollution).
Also we are talking about _generic functions_ here which are really all
about oop. They are just a nice generalisation of the concept of
For the record, in Python the concept of generic function has been there
for a very long time. Some examples are len, iter, most of what is in
the operator module.
> Also with adapter get the additional property that if an adapter adapts
> IA to IB, another one IB to IC, you get IA -> IC for free. I'm not sure
> how you get such behaviour with generic function.
Since I do not understand enough about adaptation I fear I cannot follow
Can you expand a bit, for instance giving a concrete example/use case ?
> Last but not least,
> I like the idea of interface based programming.
Well, yes, I like it too. How is this relevant to the discussion ?
More information about the Cubicweb